Node.js 的微任務(wù)處理（基于Node.js V17）
前言：Node.js 的事件循環(huán)已經(jīng)老生常談，但是在 Node.js 的執(zhí)行流程中，事件循環(huán)并不是全部，在事件循環(huán)之外，微任務(wù)的處理也是核心節(jié)點(diǎn)，比如 nextTick 和 Promise 任務(wù)的處理。本文介紹 Node.js 中微任務(wù)處理的相關(guān)內(nèi)容。網(wǎng)上文章和很多面試題中有很多關(guān)于 Promise、nextTick、setTimeout 和 setImmediate 執(zhí)行順序的內(nèi)容。通過本文，讓你從原理上理解他們，碰到相關(guān)的問題就引刃而解，不再拘泥于背誦和記錄。
1 事件循環(huán)
本文不打算詳細(xì)地講解事件循環(huán)，因?yàn)橐呀?jīng)有很多相關(guān)文章，而且本身也不是很復(fù)雜的流程。事件循環(huán)本質(zhì)上是一個(gè)消費(fèi)者和生產(chǎn)者的模型，我們可以理解事件循環(huán)的每一個(gè)階段都維護(hù)了一個(gè)任務(wù)隊(duì)列，然后在事件循環(huán)的每一輪里就會(huì)去消費(fèi)這些任務(wù)，那就是執(zhí)行回調(diào)，然后在回調(diào)里又可以生產(chǎn)任務(wù)，從而驅(qū)動(dòng)整個(gè)事件循環(huán)的運(yùn)行。當(dāng)事件循環(huán)里沒有生產(chǎn)者的時(shí)候，系統(tǒng)就會(huì)退出。而有些生產(chǎn)者會(huì) hold 住事件循環(huán)從而讓整個(gè)系統(tǒng)不會(huì)退出，比如我們啟動(dòng)了一個(gè) TCP 服務(wù)器。事件循環(huán)處理了 Node.js 中大部分的執(zhí)行流程，但是并不是全部。
2 微任務(wù)
Node.js 中，典型的微任務(wù)包括 nexiTick 和 Promise。官網(wǎng)說 nextTick 任務(wù)會(huì)在繼續(xù)事件循環(huán)之前被處理，描述得比較宏觀，下面我們來看一下具體的實(shí)現(xiàn)細(xì)節(jié)。微任務(wù)的處理時(shí)機(jī)分為兩個(gè)時(shí)間點(diǎn)。1. 定義 C++ InternalCallbackScope 對(duì)象，在對(duì)象析構(gòu)時(shí)。2. 主動(dòng)調(diào) JS 函數(shù) runNextTicks。
2.1 InternalCallbackScope
下面先看一下 InternalCallbackScope。通常在需要處理微任務(wù)的地方定義一個(gè) InternalCallbackScope 對(duì)象，然后執(zhí)行一些其他的代碼，最后退出作用域。
- {
- InternalCallbackScope scope
- // some code
- } // 退出作用域，析構(gòu)
下面看一下 InternalCallbackScope 析構(gòu)函數(shù)的邏輯。
- InternalCallbackScope::~InternalCallbackScope() {
- Close();
- }
- void InternalCallbackScope::Close() {
- tick_callback->Call(context, process, 0, nullptr);
- }
在析構(gòu)函數(shù)里會(huì)執(zhí)行 tick_callback 函數(shù)。我們看看這個(gè)函數(shù)是什么。
- static void SetTickCallback(const FunctionCallbackInfo<Value>& args) {
- Environment* env = Environment::GetCurrent(args);
- CHECK(args[0]->IsFunction());
- env->set_tick_callback_function(args[0].As<Function>());
- }
tick_callback 是由 SetTickCallback 設(shè)置的。
- setTickCallback(processTicksAndRejections);
我們可以看到通過 setTickCallback 設(shè)置的這個(gè)函數(shù)是 processTicksAndRejections。
- function processTicksAndRejections() {
- let tock;
- do {
- while (tock = queue.shift()) {
- const callback = tock.callback;
- callback();
- }
- runMicrotasks();
- } while (!queue.isEmpty() || processPromiseRejections());
- }
processTicksAndRejections 正是處理微任務(wù)的函數(shù)，包括 tick 和 Promise 任務(wù)。現(xiàn)在我們已經(jīng)了解了 InternalCallbackScope 對(duì)象的邏輯。那么下面我們來看一下哪里使用了這個(gè)對(duì)象。第一個(gè)地方是在 Node.js 初始化時(shí)，執(zhí)行完用戶 JS 后，進(jìn)入事件循環(huán)前。看看相關(guān)代碼。
我們看到在 Node.js 初始化時(shí)，執(zhí)行用戶 JS 后，進(jìn)入事件循環(huán)前會(huì)處理一次微任務(wù)，所以我們?cè)谧约旱某跏蓟?JS 里調(diào)用了 nextTick 的話，就會(huì)在這時(shí)候被處理。第二個(gè)地方是每次從 C、C++ 層執(zhí)行 JS 層回調(diào)時(shí)。
- MaybeLocal<Value> AsyncWrap::MakeCallback(const Local<Function> cb,
- int argc,
- Local<Value>* argv) {
- ProviderType provider = provider_type();
- async_context context { get_async_id(), get_trigger_async_id() };
- MaybeLocal<Value> ret = InternalMakeCallback(
- env(), object(), object(), cb, argc, argv, context);
- return ret;
- }
MakeCallback 是 C、C++ 層回調(diào) JS 層的函數(shù)，這個(gè)函數(shù)里又調(diào)用一個(gè) InternalMakeCallback。
- MaybeLocal<Value> InternalMakeCallback(Environment* env,
- Local<Object> resource,
- Local<Object> recv,
- const Local<Function> callback,
- int argc,
- Local<Value> argv[],
- async_context asyncContext) {
- // 定義 InternalCallbackScope
- InternalCallbackScope scope(env, resource, asyncContext, flags);
- // 執(zhí)行 JS 層回調(diào)
- callback->Call(context, recv, argc, argv);
- // 處理微任務(wù)
- scope.Close();
- }
我們看到 InternalMakeCallback 里定義了一個(gè) InternalCallbackScope，然后在回調(diào)完 JS 函數(shù)后會(huì)調(diào)用 InternalCallbackScope 對(duì)象的 Close 進(jìn)行微任務(wù)的處理。
以上是典型的處理時(shí)機(jī)。另外在某些地方也會(huì)定義 InternalCallbackScope 對(duì)象，具體可在源碼里搜索。
2.2 runNextTicks
剛才介紹了每次事件循環(huán)消費(fèi)任務(wù)時(shí)，就會(huì)去遍歷每一個(gè)階段的任務(wù)隊(duì)列，然后逐個(gè)執(zhí)行任務(wù)節(jié)點(diǎn)對(duì)應(yīng)的回調(diào)。執(zhí)行回調(diào)的時(shí)候，就會(huì)從 C 到 C++ 層，然后再到 JS 層，執(zhí)行完 JS 代碼后，會(huì)再次回調(diào) C++ 層，C++ 層會(huì)進(jìn)行一次微任務(wù)的處理，處理完后再回到 C 層，繼續(xù)執(zhí)行下一個(gè)任務(wù)節(jié)點(diǎn)的回調(diào)，以此類推。這看起來覆蓋了所有的情況，但是有兩個(gè)地方比較特殊，那就是 setTimeout 和 setImmediate。其他的任務(wù)都是一個(gè)節(jié)點(diǎn)對(duì)應(yīng)一個(gè) C、C++ 和 JS 回調(diào)，所以如果在 JS 回調(diào)里產(chǎn)生的微任務(wù)，在回到 C++ 層的時(shí)候就會(huì)被處理。但是為了提高性能，Node.js 的定時(shí)器和 setImmediate 在實(shí)現(xiàn)上是一個(gè)底層節(jié)點(diǎn)管理多個(gè) JS 回調(diào)。這里以定時(shí)器為例，Node.js 在底層使用了一個(gè) Libuv 的定時(shí)器節(jié)點(diǎn)管理 JS 層的所有定時(shí)器，并在 JS 層里維護(hù)了所有的定時(shí)器節(jié)點(diǎn)，然后把 Libuv 定時(shí)節(jié)點(diǎn)的超時(shí)時(shí)間設(shè)置為 JS 層最快到期的節(jié)點(diǎn)的時(shí)間，這樣就會(huì)帶來一個(gè)問題。就是當(dāng)有定時(shí)器超時(shí)，Libuv 從 C、C++ 回調(diào) JS 層時(shí)，JS 層會(huì)直接處理所有的超時(shí)節(jié)點(diǎn)后再回到 C++ 層，這時(shí)候才有機(jī)會(huì)處理微任務(wù)。這會(huì)導(dǎo)致 setTimeout 里產(chǎn)生的微任務(wù)沒有在宏任務(wù)(setTimeout 的回調(diào))執(zhí)行完后被處理。這就不符合規(guī)范了。所以這個(gè)地方還需要特殊處理一下。我們看看相關(guān)的代碼。
- function processTimers(now) {
- nextExpiry = Infinity;
- let list;
- let ranAtLeastOneList = false;
- while (list = timerListQueue.peek()) {
- if (list.expiry > now) {
- nextExpiry = list.expiry;
- return refCount > 0 ? nextExpiry : -nextExpiry;
- }
- // 處理 listOnTimeout 最后一個(gè)回調(diào)里產(chǎn)生的微任務(wù)
- if (ranAtLeastOneList)
- runNextTicks();
- else
- ranAtLeastOneList = true;
- listOnTimeout(list, now);
- }
- return 0;
- }
- function listOnTimeout(list, now) {
- let ranAtLeastOneTimer = false;
- let timer;
- while (timer = L.peek(list)) {
- // 處理微任務(wù)
- if (ranAtLeastOneTimer)
- runNextTicks();
- else
- ranAtLeastOneTimer = true;
- // 執(zhí)行 setTimeout 回調(diào)
- timer._onTimeout();
- }
- }
定時(shí)器的架構(gòu)如下。
Node.js 在 JS 層維護(hù)了一個(gè)樹，每個(gè)節(jié)點(diǎn)管理一個(gè)列表，處理超時(shí)事件時(shí)，就會(huì)遍歷這棵樹的每個(gè)節(jié)點(diǎn)，然后再遍歷這個(gè)節(jié)點(diǎn)對(duì)應(yīng)隊(duì)列里的每個(gè)節(jié)點(diǎn)。而上面的代碼就是保證在每次調(diào)用完一個(gè) setTimeout 回調(diào)時(shí)，都會(huì)處理一次微任務(wù)。同樣 setImmediate 任務(wù)也是類似的。
- let ranAtLeastOneImmediate = false;
- while (immediate !== null) {
- if (ranAtLeastOneImmediate)
- runNextTicks();
- else
- ranAtLeastOneImmediate = true;
- immediate._onImmediate();
- immediate = immediate._idleNext;
- }
以上的補(bǔ)償處理就保證了宏任務(wù)和微任務(wù)的處理能符合預(yù)期。
