好程序員web前端分享JS引擎的執(zhí)行機制

　　好程序員 web 前端分享 JS 引擎的執(zhí)行機制，請先著重牢記兩點！ JS 是單線程語言。

　　JS 的 EventLoop 是 JS 的執(zhí)行機制。深入了解 JS 的執(zhí)行，就等于深入了解 JS 里的 eventloop 。

　　1 、靈魂三問： JS 為什么是單線程的 ? 為什么需要異步 ? 單線程又是如何實現(xiàn)異步的呢 ?

　　技術(shù)的出現(xiàn)，都跟現(xiàn)實世界里的應用場景密切相關(guān)的。同樣的，我們就結(jié)合現(xiàn)實場景，來回答這三個問題。

　　(1)JS 為什么是單線程的 ?

　　JS 最初被設計用在瀏覽器中，那么想象一下，如果瀏覽器中的 JS 是多線程的。

　　場景描述：

　　那么現(xiàn)在有 2 個進程， process1process2 ，由于是多進程的 JS ，所以他們對同一個 dom ，同時進行操作。 process1 刪除了該 dom ，而 process2 編輯了該 dom ，同時下達 2 個矛盾的命令，瀏覽器究竟該如何執(zhí)行呢 ?

　　這樣想， JS 為什么被設計成單線程應該就容易理解了吧。

　　(2)JS 為什么需要異步 ?

　　場景描述：

　　如果 JS 中不存在異步，只能自上而下執(zhí)行，如果上一行解析時間很長，那么下面的代碼就會被阻塞。對于用戶而言，阻塞就意味著 " 卡死 " ，這樣就導致了很差的用戶體驗。

　　所以， JS 中存在異步執(zhí)行。

　　(3)JS 單線程又是如何實現(xiàn)異步的呢 ?

　　既然 JS 是單線程的，只能在一條線程上執(zhí)行，又是如何實現(xiàn)的異步呢 ?

　　是通過的事件循環(huán) (eventloop) ，理解了 eventloop 機制，就理解了 JS 的執(zhí)行機制。

　　2 、 JS 中的 eventloop(1)

　　例 1, 觀察它的執(zhí)行順序

　　console.log(1)setTimeout(function(){console.log(2)},0)console.log(3)

　　運行結(jié)果是： 132

　　也就是說， setTimeout 里的函數(shù)并沒有立即執(zhí)行，而是延遲了一段時間，滿足一定條件后才去執(zhí)行的，這類代碼，我們叫異步代碼。

　　所以，這里我們首先知道了 JS 里的一種分類方式，就是將任務分為：同步任務和異步任務。

　　按照這種分類方式 :JS 的執(zhí)行機制是：

　　首先判斷 JS 是同步還是異步，同步就進入主進程，異步就進入 eventtable

　　異步任務在 eventtable 中注冊函數(shù)，當滿足觸發(fā)條件后，被推入 eventqueue

　　同步任務進入主線程后一直執(zhí)行，直到主線程空閑時，才會去 eventqueue 中查看是否有可執(zhí)行的異步任務，如果有就推入主進程中

　　以上三步循環(huán)執(zhí)行，這就是 eventloop 。

　　所以上面的例子，你是否可以描述它的執(zhí)行順序了呢 ?

　　console.log(1) 是同步任務，放入主線程里

　　setTimeout() 是異步任務，被放入 eventtable ， 秒之后被推入 eventqueue 里

　　console.log(3 是同步任務，放到主線程里

　　當 1 、 3 在控制條被打印后，主線程去 eventqueue( 事件隊列 ) 里查看是否有可執(zhí)行的函數(shù)，執(zhí)行 setTimeout 里的函數(shù)。

　　3 、 JS 中的 eventloop(2)

　　所以，上面關(guān)于 eventloop 就是我對 JS 執(zhí)行機制的理解，直到我遇到了下面這段代碼。

　　例 2 ：

　　setTimeout(function(){console.log(' 定時器開始啦 ')});

　　newPromise(function(resolve){console.log(' 馬上執(zhí)行 for 循環(huán)啦 ');

　　for(vari=0;i<10000;i++){i==99&&resolve();

　　}}).then(function(){console.log(' 執(zhí)行 then 函數(shù)啦 ')});console.log(' 代碼執(zhí)行結(jié)束 ');

　　嘗試按照，上文我們剛學到的 JS 執(zhí)行機制去分析：

　　setTimeout 是異步任務，被放到 eventtable

　　newPromise 是同步任務，被放到主進程里，直接執(zhí)行打印 console.log(' 馬上執(zhí)行 for 循環(huán)啦 ')

　　.then 里的函數(shù)是異步任務，被放到 eventtable

　　console.log(' 代碼執(zhí)行結(jié)束 ') 是同步代碼，被放到主進程里，直接執(zhí)行

　　所以，結(jié)果是：馬上執(zhí)行 for 循環(huán)啦 --- 代碼執(zhí)行結(jié)束 --- 定時器開始啦 --- 執(zhí)行 then 函數(shù)啦嗎 ?

　　親自執(zhí)行后，結(jié)果居然不是這樣，而是：馬上執(zhí)行 for 循環(huán)啦 --- 代碼執(zhí)行結(jié)束 --- 執(zhí)行 then 函數(shù)啦 --- 定時器開始啦

　　那么，難道是異步任務的執(zhí)行順序，不是前后順序，而是另有規(guī)定 ? 事實上，按照異步和同步的劃分方式，并不準確。

　　而準確的劃分方式是：

　　macro-task( 宏任務 ) ：包括整體代碼 script ， setTimeout ， setInterval

　　micro-task( 微任務 ) ： Promise ， process.nextTick

　　按照這種分類方式， JS 的執(zhí)行機制是：

　　執(zhí)行一個宏任務，過程中如果遇到微任務，就將其放到微任務的 “事件隊列”里

　　當前宏任務執(zhí)行完成后，會查看微任務的 “事件隊列”，并將里面全部的微任務依次執(zhí)行完

　　重復以上 2 步驟，結(jié)合 eventloop(1)eventloop(2) ，就是更為準確的 JS 執(zhí)行機制了

　　嘗試按照剛學的執(zhí)行機制，去分析例 2 ：

　　首先執(zhí)行 script 下的宏任務，遇到 setTimeout, 將其放到宏任務的“隊列”里

　　遇到 newPromise 直接執(zhí)行，打印 " 馬上執(zhí)行 for 循環(huán)啦 "

　　遇到 then 方法，是微任務，將其放到微任務的“隊列”里。

　　打印 " 代碼執(zhí)行結(jié)束 "

　　本輪宏任務執(zhí)行完畢，查看本輪的微任務，發(fā)現(xiàn)有一個 then 方法里的函數(shù)，打印 " 執(zhí)行 then 函數(shù)啦 "

　　到此 , 本輪的 eventloop 全部完成。

　　下一輪的循環(huán)里，先執(zhí)行一個宏任務，發(fā)現(xiàn)宏任務的 “隊列”里有一個 setTimeout 里的函數(shù) , 執(zhí)行打印 " 定時器開始啦 "

　　所以最后的執(zhí)行順序是：馬上執(zhí)行 for 循環(huán)啦 --- 代碼執(zhí)行結(jié)束 --- 執(zhí)行 then 函數(shù)啦 --- 定時器開始啦

　　4 、談談 setTimeout

　　這段 setTimeout 代碼什么意思 ? 我們一般說 :3 秒后 , 會執(zhí)行 setTimeout 里的那個函數(shù)

　　setTimeout(function(){console.log(' 執(zhí)行了 ')},3000)

　　但是這種說并不嚴謹，準確的解釋是： 3 秒后， setTimeout 里的函數(shù)被會推入 eventqueue ，而 eventqueue( 事件隊列 ) 里的任務，只有在主線程空閑時才會執(zhí)行。

　　所以只有滿足 (1)3 秒后 (2) 主線程空閑，同時滿足時，才會 3 秒后執(zhí)行該函數(shù)

　　如果主線程執(zhí)行內(nèi)容很多，執(zhí)行時間超過 3 秒，比如執(zhí)行了 10 秒，那么這個函數(shù)只能 10 秒后執(zhí)行了。