從Chrome原始碼看事件迴圈
我們經常說JS的事件迴圈有微觀佇列和巨集觀佇列，所有的非同步事件都會放到這兩個佇列裡面等待執行，並且微觀佇列要先於巨集觀佇列執行。實際上事件迴圈是多執行緒的一種工作方式。通常為了提高執行效率會新起一條或多條執行緒進行並行運算，然後算完了就告知結果並退出，但是有時候並不想每次都新起執行緒，而且讓這些執行緒變成常駐的，有任務的時候工作，沒任務的時候睡眠，就可以讓這些執行緒使用事件迴圈的工作方式。
1. 常規JS事件迴圈
我們知道JS是單執行緒的，當執行一段比較長的JS程式碼時候，頁面會被卡死，無法響應，但是你所有的操作都會被另外的執行緒記錄，例如在卡死的時候點了一個按鈕，雖然不會立刻觸發回撥，但是在JS執行完的時候會觸發剛才的點選操作。所以就說有一個佇列記錄了所有待執行的操作，這個佇列又分為巨集觀和微觀，像setTimeout/ajax/使用者事件這種屬於巨集觀的，而Promise和MutationObserver屬於微觀的，微觀會比巨集觀執行得更快，如下程式碼：
setTimeout(() => console.log(0), 0);
new Promise(resolve => {
resolve();
console.log(1)
}).then(res => {
console.log(2);
});
console.log(3);
其輸出順序是1, 3, 2, 0，這裡setTimeout是巨集觀任務，所以比Promise的微觀任務慢。
2. 巨集觀任務的本質
實際上在Chrome原始碼裡面沒有任何有關巨集觀任務（MacroTask）字樣，所謂的巨集觀任務其實就是通常意義上的多執行緒事件迴圈或訊息迴圈。Chrome的所有常駐多執行緒，包括瀏覽器執行緒和頁面的渲染執行緒都是執行在事件迴圈裡的，我們知道Chrome是多程序結構的，瀏覽器程序的主執行緒和IO執行緒是統一負責地址輸入樣欄響應、網路請求載入資源等功能的瀏覽器層面的程序，而每個頁面都有獨立的程序，每個頁面程序的主執行緒是渲染執行緒，負責構建DOM、渲染、執行JS。
這些執行緒都是常駐執行緒，它們執行在一個for的死迴圈裡面，它們有若干任務佇列，不斷地執行自己或者其它執行緒通過PostTask過來的任務，或者是處於睡眠狀態直到設定的時間或者是有人PostTask的時候把它們喚醒。
通過原始碼 ofollow,noindex" target="_blank">src/base/message_loop/message_pump_default.cc 的Run函式可以知道事件迴圈的工作模式是這樣的：
void MessagePumpDefault::Run(Delegate* delegate) {
// 在一個死迴圈裡面跑著
for (;;) {
// DoWork會去執行當前所有的pending_task（放一個佇列裡面）
bool did_work = delegate->DoWork();
if (!keep_running_)
break;
// 上面的pending_task可能會建立一些delay的task，如setTimeout定時器
// 獲取到delayed的時間
did_work |= delegate->DoDelayedWork(&delayed_work_time_);
if (!keep_running_)
break;
if (did_work)
continue;
// idl的任務是在第一步沒有執行被deferred的任務
did_work = delegate->DoIdleWork();
if (!keep_running_)
break;
if (did_work)
continue;
ThreadRestrictions::ScopedAllowWait allow_wait;
if (delayed_work_time_.is_null()) {
// 沒有delay時間就一直睡著，直到有人PostTask過來
event_.Wait();
} else {
// 如果有delay的時間，那麼進行睡眠直到時間到被喚醒
event_.TimedWaitUntil(delayed_work_time_);
}
}
}
首先程式碼在一個for的死迴圈裡面執行，第一步先執行DoWork會去遍歷任務佇列裡的所有非delayed的pending_task執行，部分任務可能會被deferred到後面第三步DoIdlWork再執行，第二步是執行那些delayed的任務，如果當前不能立刻執行，那麼設定一個等待的時間delayed_work_time_，並且返回did_work是false，執行到最後面程式碼的TimedWaitUntil等待時間後喚醒執行。
這就是多執行緒事件迴圈的基本模型。那麼多執行緒要執行的task是從哪裡來的呢？
每個執行緒都有一個或多個型別的task_runner的物件，每個task_runner都有自己的任務佇列，Chrome將task分成了很多種型別，可見 task_type.h ：
kDOMManipulation = 1, kUserInteraction = 2, kNetworking = 3, kMicrotask = 9, kJavascriptTimer = 10, kSocket/">WebSocket = 12, kPostedMessage = 13, ...
訊息迴圈有自己的 message_loop_task_runner ，所有的執行緒都可以呼叫這個task_runner的PostDelayedTask傳送任務，在上面的for迴圈裡面也是通過這個task_runner的TakeTask函式取出pending的task進行執行的。在post task的時候會把task入隊同時通時喚醒執行緒：
// 需要上鎖，防止多個執行緒同時執行 AutoLock auto_lock(incoming_queue_lock_); incoming_queue_.push(std::move(pending_task)); task_source_observer_->DidQueueTask(was_empty);
這種執行緒通訊的方式其實是幾個執行緒共享了task_runner物件，所以在給它post task的時候需要上鎖。最後一行呼叫的DidQueueTask會進行通知執行緒喚醒：
// 先調
message_loop_->ScheduleWork();
// 上面的程式碼會調
pump_->ScheduleWork();
// 最後回到message_pump進行喚醒
void MessagePumpDefault::ScheduleWork() {
// Since this can be called on any thread, we need to ensure that our Run
// loop wakes up.
event_.Signal();
}
所謂的task是什麼呢？一個Task其實就是一個callback回撥，如下程式碼呼叫的第二個引數：
GetTaskRunner()->PostDelayedTask( posted_from_, BindOnce(&BaseTimerTaskInternal::Run, Owned(scheduled_task_)), delay);
等等，說了這麼多，好像和JS沒有半毛錢關係？確實沒有半毛錢關係，因為這些都是在JS執行之前的。先不要著急。
上面說的是一個預設的事件迴圈執行的程式碼，但是Mac的Chrome的渲染執行緒並不是執行的那裡的，它的事件迴圈使用了Mac的Cocoa的sdk的NSRunLoop，根據原始碼的解釋，是因為頁面的滾動條、select下拉彈框是用的Cocoa的，所以必須接入Cococa的事件迴圈機制：
#if defined(OS_MACOSX) // As long as scrollbars on Mac are painted with Cocoa, the message pump // needs to be backed by a Foundation-level loop to process NSTimers. See // http://crbug.com/306348#c24 for details. std::unique_ptr<base::MessagePump> pump(new base::MessagePumpNSRunLoop()); std::unique_ptr<base::MessageLoop> main_message_loop( new base::MessageLoop(std::move(pump))); #else // The main message loop of the renderer services doesn't have IO or UI tasks. std::unique_ptr<base::MessageLoop> main_message_loop(new base::MessageLoop()); #endif
如果是OS_MACOSX的話，訊息迴圈泵pump就是用的NSRunLoop的，否則的話就用預設的。這個泵pump的意思應該就是訊息源頭。實際上在 crbug網站 的討論裡面，Chromium原始碼的提交者們還是希望去掉渲染執行緒裡的Cococa改成用Chrome本身的Skia圖形庫畫滾動條，讓渲染執行緒不要直接響應UI/IO事件，但是沒有周期去做這件事件，從討論可以看到有人嘗試做了但是出了bug，最後又給revert回來了。
Cococa的pump和預設的pump都有統一對外的介面，例如都有一個ScheduleWork函式去喚醒執行緒，只是裡面的實現不一樣。
Chrome IO執行緒包括渲染程序的子IO執行緒在預設的pump上面又加了一個libevent.c庫提供的訊息迴圈。libevent是一個跨平臺的事件驅動的網路庫，主要是拿來做socket程式設計，以事件驅動的方式。libevent的pump檔案叫message_pump_libevent.cc，它是在預設的pump程式碼上加了一行：
bool did_work = delegate->DoWork(); if (!keep_running_) break; event_base_loop(event_base_, EVLOOP_NONBLOCK);
就是在DoWork之後看一下libevent有沒有要做的。所以可以看到它是在自己實現的事件迴圈裡面又套了libevent的事件迴圈，只不過這個libevent是nonblock，即只會執行一次就退出，但它也具備喚醒的功能。
現在來討論一些和JS相關的。
（1）使用者事件
所以當我們在頁面觸發滑鼠事件的時候，這個時候是瀏覽器的程序先收到了，然後再通過Chrome的Mojo多程序通訊的庫傳遞給頁面程序，如下圖所示：
這個Mojo的原理是用的本地socket進行的多程序通訊，所以最後是用write socket的方式。Socket是多程序通訊的一種常用方式。
頁面的程序通過打斷點觀察，應該是通過頁面程序的子IO執行緒的libevent喚醒，最後呼叫ScheduleWork通知Cococa的訊息pump：
這一點沒有得到直接的驗證，因為不太好驗證。不過結合這些庫和打斷點觀察，這樣的方式應該是比較合理，並且是很有可能的，引入libevent就能比較方便地實現這一點。
也就是說點選滑鼠訊息傳遞是這樣的：
Chromium文件也有對這個過程進行描述，但是它那個文件有點老了。
另外一種常見的非同步操作是setTimeout。
（2）setTimeout
為了研究setTimeout的行為，我們用以下JS程式碼執行：
console.log(Object.keys({a: 1}));
setTimeout(() => {
console.log(Object.keys({b: 2}));
}, 2000);
然後在 v8/src/runtime/runtime_object.cc 這個檔案的Runtime_ObjectKeys函式打個斷點，就能觀察setTimeout的執行時機，如下圖所示：
我們發現，第一次執行是在DoWork後由HTMLParserScriptParser觸發執行的，而第二次是在DoDelayedWork（最上面提到的事件迴圈模型）裡面執行的。實際上第一次執行後就會註冊一個DomTimer，這個DomTimer會post一個delayed task給主執行緒即自己，這個task裡註明了delayed時間，這樣在事件迴圈裡面這個delayed時間就會做為TimedWaitUntil的休眠時間（渲染執行緒用的是Cococa的CFRunLoopTimerSetNextFireDate）。 如下程式碼 所示：
TimeDelta interval_milliseconds = std::max(TimeDelta::FromMilliseconds(1), interval); // kMinimumInterval = 4 kMaxTimerNestingLevel = 5 // 如果嵌套了5層的setTimeout，並且時間間隔小於4ms，那麼取時間為最小值4ms if (interval_milliseconds < kMinimumInterval && nesting_level_ >= kMaxTimerNestingLevel) interval_milliseconds = kMinimumInterval; if (single_shot) StartOneShot(interval_milliseconds, FROM_HERE); else StartRepeating(interval_milliseconds, FROM_HERE);
由於是一次的setTimeout，所以會調StartOneShort，這個函式最後會調timer runner的PostTask：
並且可以看到delay的時間就是傳進去的2000ms，這裡被轉為了納秒。
在原始碼裡面可以看到，呼叫setInterval的最小時間是4ms：
// Chromium uses a minimum timer interval of 4ms. We'd like to go // lower; however, there are poorly coded websites out there which do // create CPU-spinning loops. Using 4ms prevents the CPU from // spinning too busily and provides a balance between CPU spinning and // the smallest possible interval timer. static constexpr TimeDelta kMinimumInterval = TimeDelta::FromMilliseconds(4);
目的是避免對CPU太頻繁的呼叫。實際上這個時間還要取決於作業系統能夠提供的時間精度，特別是在Windows上面。通過 time_win.cc 這個檔案我們可以瞭解到Windows能夠提供的普通時間精度誤差是10 ~ 15ms，也就是說當你setTimeout 10ms，實際上執行的間隔可能是幾毫秒也有可能是20多毫秒。所以Chrome會對delay時間做一個判斷：
#if defined(OS_WIN)
// We consider the task needs a high resolution timer if the delay is
// more than 0 and less than 32ms. This caps the relative error to
// less than 50% : a 33ms wait can wake at 48ms since the default
// resolution on Windows is between 10 and 15ms.
if (delay > TimeDelta() &&
delay.InMilliseconds() < (2 * Time::kMinLowResolutionThresholdMs)) {
pending_task.is_high_res = true;
}
#endif
如果比較設定得比較小，就會嘗試使用用高精度的時間。但是由於高精度的時間API（QPC）需要作業系統支援，並且非常耗時和耗電，所以如果筆記本沒有插電的情況是不會啟用。
另外一個問題，如果setTimeout時間為0會怎麼樣？也是一樣的，它最後也會post task，只是這個task的delayed時間是0，它就會在訊息迴圈的DoWork函式裡面執行。
需要注意的是setTimeout是存放在sequence_queue裡面的，這個是為了嚴格確保執行先後順序的（而上面訊息迴圈的佇列不能嚴格保證）。而這個sequence的didRunTask函式會當作一個task回撥拋給事件迴圈的task runner以執行自己佇列裡的task.
所以當我們執行setTimeout 0的時候就會post一個task給message loop的佇列，然後接著執行當前task的工作，如setTimeout 0後面還未執行的程式碼。
事件迴圈就討論到這裡，接下來討論下微觀任務和微觀佇列。
2. 微觀任務和微觀佇列
微觀佇列是真實存在的一個佇列，是V8裡面的一個實現。V8裡面的microtask分為以下4種（可見 microtask.h ）：
- callback
- callable
- promiseFullfil
- promiseReject
第一個callback是指普通的回撥，包括blink過來的一些回撥，如Mutation Observer應該是屬於這種。第二個callable是內部除錯用的一種任務，另外兩個是promise的完成和失敗。而promise的finally有then_finally和catch_finally內部會當作引數傳給then最後執行。
微觀任務是在什麼時候執行的呢？用以下JS進行除錯：
console.log(Object.keys({a: 1}));
setTimeout(() => {
console.log(Object.keys({b: 2}));
var promise = new Promise((resolve, reject) => {
resolve(1);
});
promise.then(res => {
console.log(Object.keys({c: 1}));
});
}, 2000);
這裡我們重點關注promise.then是什麼時候執行的。通過打斷點的呼叫棧，我們發現一個比較有趣的事情是，它是在一個解構函式裡面執行的：
把主要的程式碼抽出來是這樣的：
{
v8::MicrotasksScope microtasks_scope();
v8::MaybeLocal result = function->Call(receiver, argc, args);
}
先例項化一個scope物件，是放在棧上的，然後調function.call，這個function.call就是當前要執行的JS程式碼，等到JS執行完了，離開作用域，這個時候棧物件就會被解構，然後在解構函式裡面執行microtask。注意C++除了建構函式之外還有解構函式，解構函式是物件被銷燬時執行的，因為C++沒有自動垃圾回收，需要有個解構函式讓你自己去釋放new出來的記憶體。
也就是說微觀任務是在當前JS呼叫執行完了之後立刻執行的，是同步的，在同一個呼叫棧裡，沒有多執行緒非同步，如這裡包括promise.then在內的setTimeout回撥，還是在DOMTimer.Fired執行的，只是說then被放到了當前要執行的非同步回撥的最後面才執行。
所以setTimeout 0是給主執行緒的訊息迴圈任務佇列添加了一個新的task（回撥），而promise.then是在當前task的V8裡的microtask插入了一個任務。那麼肯定是當前正在執行的task執行完了才執行下一個task.
除了Promise，其它常見的能建立微觀任務的還有MutationObserver，Vue的$nextTick還有Promise的polyfill基本上都是用這個實現的，它的作用是就把callback當作一個微觀任務到當前同步的JS的最後面執行。當我們修改一個vue data屬性更新DOM修改時，實際上vue是重寫了Object的setter，當修改屬性時就會觸發Object的setter，這個時候vue就知道你做了修改進而去修改DOM，而這些操作都是同步JS完成的可能呼叫棧比較深，當這些呼叫棧都完成了就意味著DOM修改完了，所以nextTick能夠在DOM修改生效之後才執行。
另外，當我們在JS觸發一個請求的時候也會建立一個微觀任務：
let img = new Image();
img.src = 'image01.png?_=' + Date.now();
img.onload = function () {
console.log('img ready');
}
console.log(Object.keys({e: 1}));
我們經常會有困擾，onload是不是應該寫在src賦值的前面，避免src加上之後觸發了請求，但是onload那一行還沒執行到。實際上我們可以不用擔心的，因為執行到src賦值之後，blink會建立一個微觀任務，推到微觀佇列裡面，如下程式碼所示：
這個是ImageLoader做的enqueue操作，然後先執行最後一行的Object.keys，執行完了之後再RunMicrotasks，把剛剛入隊的任務取出來執行即載入資源的回撥。
上面enqueue的程式碼是給blink使用的，V8自己的enqueue是在builtins-internal-gen.cc這個檔案裡面的，這種builtins型別的檔案是編譯的時候直接執行生成彙編程式碼再編譯的，所以在除錯的時候原始碼是顯示成彙編程式碼的。這種不太好除錯。目的可能是直接跟據不同平臺直接生成不同的彙編程式碼，能夠加快執行速度。
最後，事件迴圈就是多執行緒的一種工作方式，Chrome裡面是使用了共享的task_runner物件給自己或者其它執行緒post task過來執行，實現方式就是用一個死迴圈不斷地取出task執行，或者休眠等待被喚醒。Mac的Chrome渲染執行緒和瀏覽器執行緒還藉助了Mac的sdk Cococa的NSRunLoop來做為UI事件的訊息源。Chrome的多程序通訊IO執行緒的本地socket通訊藉助了libevent的事件迴圈加入了到了主迴圈裡。
而微觀任務是不屬於事件迴圈的，它是V8的一個實現，用來實現Promise的then/reject，以及其它一些需要同步延後的callback，本質上它和當前的V8呼叫棧是同步執行的，只是放到了最後面。除了Promise/MutationObserver，在JS裡面發起的請求也會建立一個微觀任務延後執行。
Post Views: 2