JavaScript 是一門單線程語言,我們可以通過異步編程的方式來實現實現類似於多線程語言的並發操作。
本文着重講解通過事件循環機制來實現多個異步操作的有序執行、並發執行;通過事件隊列實現同級多個並發操作的先后執行順序,通過微任務和宏任務的概念來講解不同階段任務執行的先后順序,最后通過將瀏覽器和 Node 下的事件循環機制進行對比,對比其事件循環機制的不同之處,以及在 Node 端通過libuv引擎來實現多個異步任務的並發執行。
一、前言
我們知道JavaScript 是一門單線程語言,對於大多數人而言,單線程最大的好處是不用像多線程那樣處處在意狀態的同步問題,這里沒有死鎖的存在,也沒有像多線程之間來回切換帶來性能上的開銷。同樣,單線程也存在自身的弱點,主要表現在以下幾個方面:
-
無法利用多核cpu,一個簡單的例子,在一個位置從同一台服務器拉取不同的資源,如果采用單線程同步的方式去拉取,代碼大致如下:
getData(‘from_db’),//耗時為M, getData(‘from_db_api’),//耗時為N, 如果采用同步單線程的方式總共耗時為:M+N
-
js代碼錯誤或者耗時過長會阻塞后面代碼的執行,例如頁面在進行dom渲染時,如果頁面的js代碼報錯會引起整個頁面白屏的現象。
-
大量計算占用CPU導致無法繼續調用異步I/O。
后來HTML5定制了Web Workers能夠創建多線程來進行計算,但是使用Web Workers技術開的多線程有着諸多的限制,例如:所有新線程都受主線程的完全控制,不能獨立執行。這意味着這些“線程” 實際上應屬於主線程的子線程。另外,這些子線程並沒有執行I/O操作的權限,只能為主線程分擔一些簡單的計算任務。所以嚴格來講這些線程並沒有完整的功能,也因此這項技術並非改變了 JavaScript 語言的單線程本質。
所以我們可以預見,未來的 JavaScript 依然會是一門單線程語言,因此JavaScript采用異步編程方式實現程序“非阻塞”的特點,那么我們如何實現這一特征了,答案就是我們今天要講的——event loop(事件循環)。
二、瀏覽器下的事件循環機制
1、執行棧
JavaScript變量主要存儲在堆和棧兩個位置,其中,堆里主要存儲對象,棧主要存儲基本類型的變量以及指針變量。當我們調用一個方法時,JS 會生成一個與這個方法對應的執行環境,又叫執行上下文,當一系列方法被調用時,由於我們的js是單線程的,所以這些方法會被單獨排在一個地方,這個地方叫做執行棧。
當一個腳本第一次執行的時候,JS 引擎會解析這段代碼,並將其中的同步代碼按照執行順序加入執行棧中,然后從頭開始執行。如果當前執行的是一個方法,那么 JS 會向執行棧中添加這個方法的執行環境,然后進入這個執行環境繼續執行其中的代碼。當這個執行環境中的代碼 執行完畢並返回結果后,JS 會退出這個執行環境並把這個執行環境銷毀,回到上一個方法的執行環境。這個過程反復進行,直到執行棧中的代碼全部執行完畢。
2、事件隊列
以上說的都是 JS 同步代碼的執行,那么當程序執行異步代碼后會如何進行呢?我們前面提到過 JS 最大的特點是非阻塞,下面我們說一下實現這一點的關鍵在於這項機制——事件隊列。
當js引擎遇到一個異步事件后不會一直等待返回結果,這個事件會先掛起,繼續執行執行棧中的其他任務,直到這個異步事件的結果返回,JS 引擎會將這個事件放入與當前執行棧不同的一個隊列中,我們稱之為事件隊列。
被放入事件隊列不會立刻執行其回調,而是等待當前執行棧中的所有任務都執行完畢, 主線程處於閑置狀態時,主線程會去查找事件隊列是否有任務。如果有,那么主線程會從中取出排在第一位的事件,並把這個事件對應的回調放入執行棧中,然后執行其中的同步代碼...,如此反復,這樣就形成了一個無限的循環。這就是這個過程被稱為“事件循環(Event Loop)”的原因。
(圖片來源:網絡)
3、微任務和宏任務
關於微任務和宏任務我們可以用一張圖來說明:
(圖片來源:網絡)
在一個事件循環中,異步事件返回結果后會被放到一個任務隊列中。然而,根據這個異步事件的類型,這個事件實際上會被對應的宏任務隊列或者微任務隊列中去。並且在當前執行棧為空的時候,主線程會 查看微任務隊列是否有事件存在。如果不存在,那么再去宏任務隊列中取出一個事件並把對應的回調加入當前執行棧;如果存在,則會依次執行隊列中事件對應的回調,直到微任務隊列為空,然后去宏任務隊列中取出最前面的一個事件,把對應的回調加入當前執行棧...如此反復,進入循環。
宏任務主要包含:script( 整體代碼)、setTimeout、setInterval、I/O、UI 交互事件、setImmediate(Node.js 環境)
微任務主要包含:Promise、MutaionObserver、process.nextTick(Node.js 環境)
三、Node環境下的事件循環模型
與瀏覽器有何異同?
在 Node 中,事件循環表現出的狀態與瀏覽器中大致相同。不同的是 Node 中有一套自己的模型。Node 中事件循環的實現是依靠的libuv引擎。我們知道 Node 選擇Chrome V8引擎作為js解釋器,V8引擎將js代碼分析后去調用對應的Node api,而這些api最后則由libuv引擎驅動,執行對應的任務,並把不同的事件放在不同的隊列中等待主線程執行。因此實際上 Node 中的事件循環存在於libuv引擎中。
(圖片來源:網絡)
從上面這個模型中,我們可以大致分析出 Node 中的事件循環的順序:
外部輸入數據-->輪詢階段(poll)-->檢查階段(check)-->關閉事件回調階段(close callback)-->定時器檢測階段(timer)-->I/O事件回調階段(I/O callbacks)-->閑置階段(idle, prepare)-->輪詢階段...
以上各階段的名稱是根據我個人理解的翻譯,為了避免錯誤和歧義,下面解釋的時候會用英文來表示這些階段。這些階段大致的功能如下:
timers: 這個階段執行定時器隊列中的回調如 setTimeout() 和 setInterval()。
- I/O callbacks: 這個階段執行幾乎所有的回調。但是不包括close事件,定時器和setImmediate()的回調。
- idle, prepare: 這個階段僅在內部使用,可以不必理會。
- poll: 等待新的I/O事件,node在一些特殊情況下會阻塞在這里。
- check: setImmediate()的回調會在這個階段執行。
- close callbacks: 例如socket.on('close', ...)這種close事件的回調。
四、小結
JavaScript事件循環是非常重要的一個基礎概念,我們可以通過這種機制實現異步編程,解決JavaScript同步單線程無法實現並發操作的問題,可以使我們對一段異步代碼的執行順序有一個清晰的認識,從而減少代碼運行的不確定性。合理的使用各種延遲事件的方法,有助於代碼更好的按照其優先級去執行。
作者:Liu Gang