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

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

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

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

　　技術的出現，都跟現實世界里的應用場景密切相關的。同樣的，我們就結合現實場景，來回答這三個問題。

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

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

　　場景描述：

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

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

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

　　場景描述：

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

　　所以， JS 中存在異步執行。

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

　　既然 JS 是單線程的，只能在一條線程上執行，又是如何實現的異步呢 ?

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

　　2 、 JS 中的 eventloop(1)

　　例 1, 觀察它的執行順序

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

　　運行結果是： 132

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

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

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

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

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

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

　　以上三步循環執行，這就是 eventloop 。

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

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

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

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

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

　　3 、 JS 中的 eventloop(2)

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

　　例 2 ：

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

　　newPromise(function(resolve){console.log(' 馬上執行 for 循環啦 ');

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

　　}}).then(function(){console.log(' 執行 then 函數啦 ')});console.log(' 代碼執行結束 ');

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

　　setTimeout 是異步任務，被放到 eventtable

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

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

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

　　所以，結果是：馬上執行 for 循環啦 --- 代碼執行結束 --- 定時器開始啦 --- 執行 then 函數啦嗎 ?

　　親自執行后，結果居然不是這樣，而是：馬上執行 for 循環啦 --- 代碼執行結束 --- 執行 then 函數啦 --- 定時器開始啦

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

　　而準確的劃分方式是：

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

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

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

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

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

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

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

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

　　遇到 newPromise 直接執行，打印 " 馬上執行 for 循環啦 "

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

　　打印 " 代碼執行結束 "

　　本輪宏任務執行完畢，查看本輪的微任務，發現有一個 then 方法里的函數，打印 " 執行 then 函數啦 "

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

　　下一輪的循環里，先執行一個宏任務，發現宏任務的 “隊列”里有一個 setTimeout 里的函數 , 執行打印 " 定時器開始啦 "

　　所以最后的執行順序是：馬上執行 for 循環啦 --- 代碼執行結束 --- 執行 then 函數啦 --- 定時器開始啦

　　4 、談談 setTimeout

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

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

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

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

　　如果主線程執行內容很多，執行時間超過 3 秒，比如執行了 10 秒，那么這個函數只能 10 秒后執行了。