標籤: eventloop 事件機制 nodejavascript
原文地址:Tasks, microtasks, queues and scheduleshtml
鑑於上篇文章有提到過 微任務與宏任務,因此,在此作個細緻補充: 話很少說,直接進入正文:前端
[1] 本文主要根據網上資源總結而來,若有不對,請斧正。 [2] 須要知道的專業名詞術語:synchronous:同步任務、asynchronous:異步任務、task queue/callback queue:任務隊列、execution context stack:執行棧、heap:堆、stack:棧、macro-task:宏任務、micro-task:微任務html5
js是單線程,就像學生排隊上廁所,學生須要排隊一個一個上廁所,同理js任務也要一個一個順序執行。若是一個任務耗時過長,那麼後一個任務也必須等着。那麼問題來了,假如咱們想瀏覽新聞,可是新聞包含的超清圖片加載很慢,難道咱們的網頁要一直卡着直到圖片徹底顯示出來?所以聰明的程序員將任務分爲兩類:java
從圖片可知,一個方法執行會向執行棧中加入這個方法的執行環境,在這個執行環境中還能夠調用其餘方法,甚至是本身,其結果不過是在執行棧中再添加一個執行環境。這個過程能夠是無限進行下去的,除非發生了棧溢出,即超過了所能使用內存的最大值。node
當咱們打開網站時,網頁的渲染過程就是一大堆同步任務,好比頁面骨架和頁面元素的渲染。而像加載圖片音樂之類佔用資源大耗時久的任務,就是異步任務。關於這部分有嚴格的文字定義,但本文的目的是用最小的學習成本完全弄懂執行機制程序員
console.log('script start');
setTimeout(function() {
console.log('setTimeout');
}, 0);
Promise.resolve().then(function() {
console.log('promise1');
}).then(function() {
console.log('promise2');
});
console.log('script end');
複製代碼
打印順序是什麼? 正確答案是:script start, script end, promise1, promise2, setTimeout 已蒙圈。。。es6
解讀:ajax
咱們不由要問了,那怎麼知道主線程執行棧爲空呢?js引擎存在monitoring process進程,會持續不斷的檢查主線程執行棧是否爲空,一旦爲空,就會去Event Queue那裏檢查是否有等待被調用的函數。chrome
看代碼:
let data = [];
$.ajax({
url:www.javascript.com,
data:data,
success:() => {
console.log('發送成功!');
}
})
console.log('代碼執行結束');
複製代碼
上面是一段簡易的ajax請求代碼:
相信經過上面的文字和代碼,你已經對js的執行順序有了初步瞭解。
一個掘金的老哥(ssssyoki)的文章摘要: 那麼如此看來我給的答案仍是對的。可是js異步有一個機制,就是遇到宏任務,先執行宏任務,將宏任務放入eventqueue,而後在執行微任務,將微任務放入eventqueue最騷的是,這兩個queue不是一個queue。當你往外拿的時候先從微任務裏拿這個回掉函數,而後再從宏任務的queue上拿宏任務的回掉函數。 我當時看到這我就服了還有這種騷操做。
不廢話,看如下例子:
大名鼎鼎的setTimeout無需再多言,你們對他的第一印象就是異步能夠延時執行,咱們常常這麼實現延時3秒執行:
setTimeout(() => {
console.log('延時3秒');
},3000)
複製代碼
漸漸的setTimeout用的地方多了,問題也出現了,有時候明明寫的延時3秒,實際卻5,6秒才執行函數,這又咋回事啊?
setTimeout(() => {
task();
},3000)
console.log('執行console');
複製代碼
根據前面咱們的結論,setTimeout是異步的,應該先執行console.log這個同步任務,因此咱們的結論是:
// 執行console
// task()
複製代碼
去驗證一下,結果正確! 而後咱們修改一下前面的代碼:
setTimeout(() => {
task()
},3000)
sleep(10000000)
複製代碼
乍一看其實差很少嘛,但咱們把這段代碼在chrome執行一下,卻發現控制檯執行task()須要的時間遠遠超過3秒,說好的延時三秒,爲啥如今須要這麼長時間啊? 這時候咱們須要從新理解setTimeout
的定義。咱們先說上述代碼是怎麼執行的:
上述的流程走完,咱們知道setTimeout這個函數,是通過指定時間後,把要執行的任務(本例中爲task())加入到Event Queue中,又由於是單線程任務要一個一個執行,若是前面的任務須要的時間過久,那麼只能等着,致使真正的延遲時間遠遠大於3秒。
咱們還常常遇到setTimeout(fn,0)
這樣的代碼,0秒後執行又是什麼意思呢?是否是能夠當即執行呢? 答案是不會的,setTimeout(fn,0)
的含義是,指定某個任務在主線程最先可得的空閒時間執行,意思就是不用再等多少秒了,只要主線程執行棧內的同步任務所有執行完成,棧爲空就立刻執行。舉例說明:
//代碼1
console.log('先執行這裏');
setTimeout(() => {
console.log('執行啦')
},0);
//代碼2
console.log('先執行這裏');
setTimeout(() => {
console.log('執行啦')
},3000);
複製代碼
代碼1的輸出結果是:
先執行這裏
執行啦
複製代碼
代碼2的輸出結果是:
//先執行這裏
// ... 3s later
// 執行啦
複製代碼
關於setTimeout要補充的是,即使主線程爲空,0毫秒實際上也是達不到的。根據HTML的標準,最低是4毫秒。有興趣的同窗能夠自行了解。
上面說完了setTimeout
,固然不能錯過它的孿生兄弟setInterval
。他倆差很少,只不事後者是循環的執行。對於執行順序來講,setInterval
會每隔指定的時間將註冊的函數置入Event Queue,若是前面的任務耗時過久,那麼一樣須要等待。
惟一須要注意的一點是,對於setInterval(fn,ms)
來講,咱們已經知道不是每過ms秒會執行一次fn,而是每過ms秒,會有fn進入Event Queue。一旦setInterval的回調函數fn執行時間超過了延遲時間ms,那麼就徹底看不出來有時間間隔了。這句話請讀者仔細品味。
setTimeout
和setInterval
會進入相同的Event Queue。看例子:
setTimeout(()=>{
console.log('setTimeout1')
},0)
let p = new Promise((resolve,reject)=>{
console.log('Promise1')
resolve()
})
p.then(()=>{
console.log('Promise2')
})
複製代碼
Promise參數中的Promise1是同步執行的 其次是由於Promise是microtasks,會在同步任務執行完後會去清空microtasks queues, 最後清空完微任務再去宏任務隊列取值。
Promise.resolve().then(()=>{
console.log('Promise1')
setTimeout(()=>{
console.log('setTimeout2')
},0)
})
setTimeout(()=>{
console.log('setTimeout1')
Promise.resolve().then(()=>{
console.log('Promise2')
})
},0)
複製代碼
Promise1
,同時會生成一個異步任務 setTimeout1setTimeout1
Promise2
setTimeout2
以下圖:
最後咱們來分析一段較複雜的代碼,看看你是否真的掌握了js的執行機制:
console.log('1');
setTimeout(function() {
console.log('2');
process.nextTick(function() {
console.log('3');
})
new Promise(function(resolve) {
console.log('4');
resolve();
}).then(function() {
console.log('5')
})
})
process.nextTick(function() {
console.log('6');
})
new Promise(function(resolve) {
console.log('7');
resolve();
}).then(function() {
console.log('8')
})
setTimeout(function() {
console.log('9');
process.nextTick(function() {
console.log('10');
})
new Promise(function(resolve) {
console.log('11');
resolve();
}).then(function() {
console.log('12')
})
})
複製代碼
第一輪事件循環流程分析以下:
1
。setTimeout1
。process1
。then1
。setTimeout2
。宏任務Event Queue | 微任務Event Queue |
---|---|
setTimeout1 | process1 |
setTimeout2 | then1 |
1
和7
。咱們發現了process1和then1兩個微任務。
6
。8
。好了,第一輪事件循環正式結束,這一輪的結果是輸出1,7,6,8
。那麼第二輪時間循環從setTimeout1宏任務開始:
2
。接下來遇到了process.nextTick(),一樣將其分發到微任務Event Queue中,記爲process2。4
,then也分發到微任務Event Queue中,記爲then2宏任務Event Queue | 微任務Event Queue |
---|---|
setTimeout2 | process3 |
then3 |
第三輪事件循環宏任務執行結束,執行兩個微任務process3和then3。
輸出10
。
輸出12
。
第三輪事件循環結束,第三輪輸出9,11,10,12
。
整段代碼,共進行了三次事件循環,完整的輸出爲1,7,6,8,2,4,3,5,9,11,10,12
。(請注意,node環境下的事件監聽依賴libuv與前端環境不徹底相同,輸出順序可能會有偏差)
但願你們看了本篇文章都有收穫 ...