Event Loop階段描述圖

timers

timer階段處理setTimeout于setInterval回調(diào)，開(kāi)始處理的時(shí)機(jī)與poll階段有關(guān)聯(lián)。

pending callbacks

該階段執(zhí)行某些系統(tǒng)操作的回調(diào)，比如TCP套接字在連接時(shí)收到ECONNREFUSED。

網(wǎng)上有一些將該階段稱為I/O callbacks的文章都是過(guò)時(shí)錯(cuò)誤的，具體可以移步Node.js官方庫(kù)下面的這個(gè)issue: #1118。

idle, prepare

內(nèi)部使用，忽略。

poll

poll是一個(gè)核心階段，等新I/O事件的觸發(fā)，以及執(zhí)行I/O相關(guān)回調(diào)。Node.js中出現(xiàn)異步的絕大部分情況都是I/O操作，它們的回調(diào)基本都在這個(gè)階段被執(zhí)行。

poll階段主要做兩件事：

• 計(jì)算需要為新的的I/O事件等待多久

當(dāng)進(jìn)入poll階段，如果隊(duì)列為空且不存在setImmediate與就緒的timer，Node.js會(huì)在這里block一定的時(shí)間等待新的I/O事件到來(lái)，然后立即執(zhí)行其回調(diào)。這種情況具體block等待多久是不具體的，但如果在block一定時(shí)間后仍沒(méi)有新到達(dá)的I/O事件，可以肯定循環(huán)依舊會(huì)進(jìn)入check階段或者回到timer階段。

• 處理該階段隊(duì)列中的事件

當(dāng)進(jìn)入poll階段，如果隊(duì)列不為空且沒(méi)有就緒的timer，Node.js會(huì)在這里執(zhí)行隊(duì)列中的callback直到隊(duì)列為空或者執(zhí)行的callback數(shù)達(dá)到系統(tǒng)設(shè)定的某個(gè)值。隨后Node.js檢查是否存在預(yù)設(shè)的setImmediate，存在話就進(jìn)入check階段，否則開(kāi)始檢查timer就緒情況選擇回到timer階段或者進(jìn)入check階段。

對(duì)于poll階段，通過(guò)閱讀官方的文檔有些細(xì)節(jié)也沒(méi)弄清楚，用偽代碼表示出來(lái)：

enter pool phase:
if (has timer scheduled) {
  // 官方?jīng)]有提到這種情況會(huì)做什么
}
else {
  if (isEmpty(queue)) {
    if (has(setImmediate)) {
      // 進(jìn)入check階段
    }
    else if (!isEmpty(timer)) {
      // 回到timer階段
    }
    else {
      // 等待新的I/O事件
      // 新的I/O事件觸發(fā)回調(diào)立即執(zhí)行，執(zhí)行完成之后的邏輯不清楚
    }
    // 目前看來(lái)只有存在setImmediate時(shí)才會(huì)進(jìn)入check階段，這肯定不合理
  }
  if (!isEmpty(queue)) {
    let result = execute(queue);
    if (result === 'queue is empty') {
      // 官方?jīng)]講后續(xù)邏輯
      // 猜測(cè)是回到隊(duì)列為空的處理邏輯中
    }
    if (result === 'reached hard limit') {
      // 官方?jīng)]有解釋這里的后續(xù)邏輯
      // 也許與queue is empty一樣對(duì)待
    }
  }
}

疑惑重點(diǎn)是從poll階段出來(lái)的時(shí)機(jī)以及去向不是非常明確，但以我目前的水平和精力只能到此為止。

check

當(dāng)poll階段執(zhí)行完成會(huì)進(jìn)入到check階段執(zhí)行，該階段的執(zhí)行內(nèi)容是所有setImmediate回調(diào)。

close callbacks

socket的異常關(guān)閉，'close'事件的回調(diào)會(huì)在該階段執(zhí)行。

process.nextTick

process.nextTick經(jīng)常被用來(lái)做異步調(diào)用，但它并不屬于事件循環(huán)的內(nèi)容，process.nextTick中的回調(diào)被放在nextTickQueue中等待“當(dāng)前操作”完成后被立即處理，與事件循環(huán)中的階段沒(méi)有聯(lián)系，當(dāng)前操作的原文定義是：“An operation is defined as a transition from the underlying C/C++ handler, and handling the JavaScript that needs to be executed.”，指的是在一段Javascript代碼執(zhí)行完切換到C/C++層時(shí)會(huì)處理nextTickQueue。

文章提到了一個(gè)特例是Deduplication，這是Node.js內(nèi)部一個(gè)優(yōu)化特性，當(dāng)在timer和check階段，同時(shí)有多個(gè)需要執(zhí)行的回調(diào)時(shí)，切換只會(huì)發(fā)生一次，所以nextTick回調(diào)執(zhí)行在這種情況下看似有所延后。

代碼示例：

setImmediate(() => {
  console.log('1');
  process.nextTick(() => console.log('2'));
});
setImmediate(() => {
  console.log('3');
  process.nextTick(() => console.log('4'));
});

存在兩個(gè)setImmediate，進(jìn)入check階段后需要在執(zhí)行所有setImmediate的回調(diào)代碼后才會(huì)產(chǎn)生切換，從而執(zhí)行nextTick回調(diào)，因此上面代碼的運(yùn)行結(jié)果是：“1 3 2 4”，除上述場(chǎng)景外，nextTick都會(huì)先于setImmediate執(zhí)行。

總結(jié)

因?yàn)镹ode.js的Event Loop我看了有那么2、3回，但經(jīng)常忘，所以這次記錄下來(lái)，做個(gè)備忘。由于太多知識(shí)容易忘記，又發(fā)現(xiàn)寫文章的一個(gè)優(yōu)點(diǎn)：“幫助記憶便于復(fù)習(xí)”。

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

最新評(píng)論