[[412788]]

調用棧 Call Stack

正式闡述任務隊列與事件循環，大概了解一下 JavaScript 是如何運行的：

在 JavaScript 運行的時候，主線程會形成一個棧，這個棧主要是解釋器用來最終函數執行流的一種機制。通常這個棧被稱為調用棧 Call Stack ，或者執行棧（ Execution Context Stack ）。

調用棧，顧名思義是具有LIFO（后進先出，Last in First Out）的結構。調用棧內存放的是代碼執行期間的所有執行上下文。

• 每調用一個函數，解釋器就會把該函數的執行上下文添加到調用棧并開始執行；

• 正在調用棧中執行的函數，如果還調用了其他函數，那么新函數也會被添加到調用棧，并立即執行；

• 當前函數執行完畢后，解釋器會將其執行上下文清除調用棧，繼續執行剩余執行上下文中的剩余代碼；

• 但分配的調用棧空間被占滿，會引發”堆棧溢出“的報錯。

調用棧 Call Stack參考文章：

1、 juejin.cn/post/696902… ^[1]

2、 blog.csdn.net/ch834301/ar… ^[2]

1. 為何需要有任務隊列與循環事件

1、JavaScript 是 單線程的 ：一次只能運行一個任務。通常，這沒什么大不了的，但是現在想象你正在運行一個耗時 30 秒的任務，比如請求數據、定時器、讀取文件等等。在此任務中，我們等待 30 秒才能進行其他任何操作（默認情況下，JavaScript 在瀏覽器的主線程上運行，因此整個用戶界面都停滯了），后面的語句就得一直等著前面的語句執行結束后才會開始執行 。

都到 2021 年了，沒有人想停留在一個速度慢，交互反應遲鈍的網站。

2、瀏覽器每個渲染進程都有一個主線程，并且主線程非常繁忙，既要處理 DOM，又 要計算樣式，還要處理布局，同時還需要處理 JavaScript 任務以及各種輸入事件。要讓這 么多不同類型的任務在主線程中有條不紊地執行，這就需要一個系統來統籌調度這些任務， 這個統籌調度系統就是我們今天要講的消息隊列和事件循環系統。

（不清楚瀏覽器渲染時候，進程線程如何運行的同學，等我下一篇文章總結一下，后期我會加入文章鏈接）

3、要想在線程運行過程中，能接收并執行新的任務，就需要采用事件循環機制。

4、能夠接收其他線程發送的消息呢，一個通用模式是使用消息隊列。

同步任務和異步任務

因此， JavaScript 將所有執行任務分為了同步任務和異步任務。

其實我們每個任務都是在做兩件事情，就是 發起調用 和 得到結果 。

而同步任務和異步任務最主要的差別就是，同步任務發起調用后，很快就可以得到結果，而異步任務是無法立即得到結果，比如請求接口，每個接口都會有一定的響應時間，根據網速、服務器等等因素決定，再比如定時器，它需要固定時間后才會返回結果。

因此，對于同步任務和異步任務的執行機制也不同。

同步任務的執行，其實就是跟前面那個案例一樣，按照代碼順序和調用順序，支持進入調用棧中并執行，執行結束后就移除調用棧。

而異步任務的執行，首先它依舊會進入調用棧中，然后發起調用，然后解釋器會將其 響應回調任務 放入一個 任務隊列 ，緊接著調用棧會將這個任務移除。當主線程清空后，即所有同步任務結束后，解釋器會讀取任務隊列，并依次將 已完成的異步任務 加入調用棧中并執行。

這里有個重點，就是異步任務不是直接進入任務隊列的，等執行到異步函數（任務）的回調函數推入到任務隊列中。

img-blog.csdnimg.cn/20210629235… ^[3]

任務入隊

這里還有一個知識點，就是關于任務入隊。

任務進入任務隊列，其實會利用到瀏覽器的其他線程。雖然說 JavaScript 是單線程語言，但是瀏覽器不是單線程的。而不同的線程就會對不同的事件進行處理，當對應事件可以執行的時候，對應線程就會將其放入任務隊列。

• js引擎線程：用于解釋執行js代碼、用戶輸入、網絡請求等；

• GUI渲染線程：繪制用戶界面，與JS主線程互斥（因為js可以操作DOM，進而會影響到GUI的渲染結果）；

• http異步網絡請求線程：處理用戶的get、post等請求，等返回結果后將回調函數推入到任務隊列；

• 定時觸發器線程 ： setInterval 、 setTimeout 等待時間結束后，會把執行函數推入任務隊列中；
• 瀏覽器事件處理線程 ：將 click 、 mouse 等UI交互事件發生后，將要執行的回調函數放入到事件隊列中。

2. 任務隊列與循環事件到底是個啥

1、消息（任務）隊列

消息隊列是一種數據結構，可以存放要執行的任務。它符合隊列“先進先出”的特點，也就是說要添加任務的話，添加到隊列的尾部；要取出任務的話，從隊列頭部去取。

在任務隊列中，其實還分為 宏任務隊列（Task Queue）**和**微任務隊列（Microtask Queue） ，對應的里面存放的就是 宏任務 和 微任務 。

首先，宏任務和微任務都是異步任務。

補充個知識點：1、常見的宏任務：script(整體代碼) setTimeout setInterval I/O UI交互事件 postMessage MessageChannel setImmediate(Node.js 環境) 2、常見的微任務：Promise.then Object.observe MutaionObserver process.nextTick(Node.js 環境)

2、事件循環系統

事件循環系統就是在監聽并執行消息隊列中的任務

3. 任務隊列與循環事件具體如何使用

事件循環 Event Loop

其實宏任務隊列和微任務隊列的執行，就是事件循環的一部分了，所以放在這里一起說。

事件循環的具體流程如下：

1. 從宏任務隊列中，按照 入隊順序 ，找到第一個執行的宏任務，放入調用棧，開始執行；

2. 執行完 該宏任務 下所有同步任務后，即調用棧清空后，該宏任務被推出宏任務隊列，然后微任務隊列開始按照入隊順序，依次執行其中的微任務， 直至微任務隊列清空為止 ；

3. 當微任務隊列清空后，一個事件循環結束；

4. 接著從宏任務隊列中，找到下一個執行的宏任務，開始第二個事件循環，直至宏任務隊列清空為止。

這里有幾個重點：

• 當我們第一次執行的時候，解釋器會將整體代碼 script 放入宏任務隊列中，因此事件循環是從第一個宏任務開始的；

• 如果在執行微任務的過程中，產生新的微任務添加到微任務隊列中，也需要一起清空；微任務隊列沒清空之前，是不會執行下一個宏任務的。

4. 詳解宏任務（如： setTimeout() ）

為了協調這些任務有條不紊地在主線程上執行，頁面進程引入了消息隊列和事件循環機制， 渲染進程內部會維護多個消息隊列，比如（延遲執行隊列和普通的消息隊列）。然后主線程采用 一個 for 循環，不斷地從這些任務隊列中取出任務并執行任務。我們把這些消息隊列中的任 務稱為宏任務。

• 當我們第一次執行的時候，解釋器會將整體代碼 script 放入宏任務隊列中，因此事件循環是從第一個宏任務開始的；

• 如果在執行微任務的過程中，產生新的微任務添加到微任務隊列中，也需要一起清空；微任務隊列沒清空之前，是不會執行下一個宏任務的。

參考文章：

1、 juejin.cn/post/696902… ^[5]

5. 詳解微任務（如：promise、MutationObserver）

微任務就是一個需要異步執行的函數，執行時機是在主函數執行結束之后、當前宏任務結束 之前。

我們知道當 JavaScript 執行一段腳本的時候，V8 會為其創建一個全局執行上下文，在創建 全局執行上下文的同時，V8 引擎也會在內部創建一個微任務隊列。顧名思義，這個微任務 隊列就是用來存放微任務的，因為在當前宏任務執行的過程中，有時候會產生多個微任務， 這時候就需要使用這個微任務隊列來保存這些微任務了。不過這個微任務隊列是給 V8 引擎 內部使用的，所以你是無法通過 JavaScript 直接訪問的。

也就是說每個宏任務都關聯了一個微任務隊列。那么接下來，我們就需要分析兩個重要的時 間點——微任務產生的時機和執行微任務隊列的時機。我們先來看看微任務是怎么產生的？在現代瀏覽器里面，產生微任務有兩種方式。第一種方式是使用 MutationObserver 監控某個 DOM 節點，然后再通過 JavaScript 來修 改這個節點，或者為這個節點添加、刪除部分子節點，當 DOM 節點發生變化時，就會產 生 DOM 變化記錄的微任務。第二種方式是使用 Promise，當調用 Promise.resolve() 或者 Promise.reject() 的時候，也 會產生微任務。

好了，現在微任務隊列中有了微任務了，那接下來就要看看微任務隊列是何時被執行的。通常情況下，在當前宏任務中的 JavaScript 快執行完成時，也就在 JavaScript 引擎準備退 出全局執行上下文并清空調用棧的時候，JavaScript 引擎會檢查全局執行上下文中的微任 務隊列，然后按照順序執行隊列中的微任務。WHATWG 把執行微任務的時間點稱為檢查 點。當然除了在退出全局執行上下文式這個檢查點之外，還有其他的檢查點，不過不是太重 要，這里就不做介紹了。如果在執行微任務的過程中，產生了新的微任務，同樣會將該微任務添加到微任務隊列中， V8 引擎一直循環執行微任務隊列中的任務，直到隊列為空才算執行結束。也就是說在執行 微任務過程中產生的新的微任務并不會推遲到下個宏任務中執行，而是在當前的宏任務中繼 續執行。

Demo案例：

該示意圖是在執行一個 ParseHTML 的宏任務，在執行過程中，遇到了 JavaScript 腳本， 那么就暫停解析流程，進入到 JavaScript 的執行環境。從圖中可以看到，全局上下文中包 含了微任務列表。在 JavaScript 腳本的后續執行過程中，分別通過 Promise 和 removeChild 創建了兩個微 任務，并被添加到微任務列表中。接著 JavaScript 執行結束，準備退出全局執行上下文， 這時候就到了檢查點了，JavaScript 引擎會檢查微任務列表，發現微任務列表中有微任 務，那么接下來，依次執行這兩個微任務。等微任務隊列清空之后，就退出全局執行上下 文。

注意點：

微任務和宏任務是綁定的，每個宏任務在執行時，會創建自己的微任務隊列。微任務的執行時長會影響到當前宏任務的時長。比如一個宏任務在執行過程中，產生了 100 個微任務，執行每個微任務的時間是 10 毫秒，那么執行這 100 個微任務的時間就 是 1000 毫秒，也可以說這 100 個微任務讓宏任務的執行時間延長了 1000 毫秒。所以 你在寫代碼的時候一定要注意控制微任務的執行時長。在一個宏任務中，分別創建一個用于回調的宏任務和微任務，無論什么情況下，微任務都 早于宏任務執行。

參考文章：

1、 time.geekbang.org/column/arti… ^[6]

6. 詳解async、await

async 會將其后的函數（函數表達式或 Lambda）的返回值封裝成一個 Promise 對象，而 await 會等待這個 Promise 完成，并將其 resolve 的結果返回出來。

ES7 引入了一個新的在 JavaScript 中添加異步行為的方式并且使 promise 用起來更加簡單！隨著 async 和 await 關鍵字的引入，我們能夠創建一個隱式的返回一個 promise 的 async` 函數。但是，我們該怎么做呢？

之前，我們看到不管是通過輸入 new Promise(() => {}) ， Promise.resolve 或 Promise.reject ，我們都可以顯式的使用 Promise 對象創建 promise 。

我們現在能夠創建隱式地返回一個對象的異步函數，而不是顯式地使用 Promise 對象！這意味著我們不再需要寫任何 Promise 對象了。

盡管 async 函數隱式的返回 promise 是一個非常棒的事實，但是在使用 await 關鍵字的時候才能看到 async 函數的真正力量。當我們等待 await 后的值返回一個 resolved 的 promise 時，通過 await 關鍵字，我們可以暫停異步函數。如果我們想要得到這個 resolved 的 promise 的值，就像我們之前用 then 回調那樣，我們可以為被 await 的 promise 的值賦值為變量！

具體案例請參考下面五星文章哦，

五星提醒必看文章：

1、驚艷！可視化的 js：動態圖演示 Promises & Async/Await 的過程！

mp.weixin.qq.com/s\?\_\_biz=MzA… ^[7]

2、驚艷！可視化的 js：動態圖演示 - 事件循環 Event Loop

blog.csdn.net/ch834301/ar… ^[8]

• 原文地址： dev.to/lydiahallie… ^[9]

• 原文作者：Lydia Hallie

一個js函數簡單執行流程(簡單總結）：

一個js函數簡單執行流程：

先執行該函數里面的同步方法，全部執行完同步任務以后， 比如:var num=10 , console.log('timeout') 這種步驟

再執行微任務的回調函數，全部執行完微任務的回調函數， 比如:Promise.resolve(5).then(res => res_2).then(res => res_2)

最后執行該函數里面的宏任務的回調函數。比如：setTimeout(() => { console.log('timeout') },0)

（前提：不同任務存在的情況下，沒有就不執行）---