您好,登錄后才能下訂單哦!
小編給大家分享一下Node.js中Event Loop各階段的示例分析,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
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í)行。
以上是“Node.js中Event Loop各階段的示例分析”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對(duì)大家有所幫助,如果還想學(xué)習(xí)更多知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。