摘要:運行執行上下文正在使用的執行上下文。頂部是正在執行的上下文當執行完畢,它的執行上下文自動從棧彈出,控制流程按順序到達全局執行上下文。一旦所有代碼執行完畢,引擎從當前棧中移除全局執行上下文。在全局執行上下文中,的值指向全局對象。
https://juejin.im/post/5ba321...
https://juejin.im/entry/59986...
我只是搬運工,看了他們的文章后深有啟發,于是把他們的精華匯總然后加入自己的理解整理了這一篇文章。
這是一個非常抽象的概念,你無需徹底的弄明白它的意思,你只需要明白它做了什么。
在充分理解他做了什么之前還是要了解一下它到底是什么
Execution Context(執行上下文)是 ECMA-262 標準中定義的一個抽象概念,用于同 Executable
Code(可執行代碼)進行區分。
1:什么是執行代碼----Executable Code
合法的,可以被解釋器解析執行的代碼。
分為三類
Global Code:全局代碼
Function Code:函數體內的代碼
Eval Code:使用 eval() 函數執行的代碼
2:什么是執行上下文----Execution Context
執行上下文 是 ES 用來跟蹤代碼運行狀態和相關資源集合的特殊機制。它決定了執行代碼執行的過程中可以訪問的數據。每當 Javascript 代碼在運行的時候,它都是在執行上下文中運行。
分為三類
Global Execution Context:全局執行上下文
這是默認或者說基礎的上下文,任何不在函數內部的代碼都在全局上下文中執行。它會執行兩件事:創建一個全局的 window
對象(瀏覽器的情況下),并且設置 this 的值等于這個全局對象。一個程序中只會有一個全局執行上下文。
Function Execution Context:函數執行上下文
每當一個函數被調用時, 都會為該函數創建一個新的上下文。每個函數被調用時都有它自己的執行上下文。函數上下文可以有任意多個。每當一個新的執行上下文被創建,它會按定義的順序(將在后文討論)執行一系列步驟。
Eval Execution Context:eval() 函數執行上下文
由于 JavaScript 開發者并不經常使用 eval,所以在這里我不會討論它。
3:執行上下文的基本工作方式
先理解兩個名詞:執行上下文棧(Execution Context Stack)、運行執行上下文(Running Execution Context)
執行上下文棧( Execution Context Stack ):用來保存所有執行上下文的棧,是一種擁有 LIFO(后進先出)數據結構的棧。 當 JavaScript 引擎第一次遇到你的腳本時,它會創建一個全局的執行上下文并且壓入當前執行棧。每當引擎遇到一個函數調用,它會為該函數創建一個新的執行上下文并壓入棧的頂部。引擎會執行那些執行上下文位于棧頂的函數。當該函數執行結束時,執行上下文從棧中彈出,控制流程到達當前棧中的下一個上下文。
運行執行上下文( Running Execution Context ):正在使用的執行上下文。在任意時間,最多只能有一
個正在運行代碼的執行上下文。
4:基本工作方式
運行執行上下文總是在執行上下文棧的頂部,全局執行上下文總在執行上下文棧的底部。無論什么時候,只要控制權從與當前運行執行上下文相關的可執行代碼上切換到另一部分與當前運行執行上下文不相關的可執行代碼上,一個新的執行上下文就會被創建,新創建的執行上下文會被放在當前的運行執行上下文的上面,成為新的運行執行上下文。
5:具體工作流程
如前言中提到的,ES 標準中并沒有從技術實現的角度定義執行上下文準確類型和結構,為了更方便地解釋
執行代碼和執行上下文之間的關系,暫且用數組表示執行上下文棧,然后用偽代碼來操作執行上下文棧:
DCStack = [] // 執行上下文棧
<1:開始執行代碼:全局執行代碼與全局執行上下文
解析器在解析執行代碼時首先執行全局代碼,為其創建對應的執行上下文,全局上下文被壓入執行上下文棧
ECStack = [ globalContext // 全局執行上下文 ]
<2:開始執行函數:函數代碼與函數執行上下文
注意:函數代碼中不包括內部函數的代碼
運行下面的函數 (function foo(bar) { if (bar) { return } foo(true); })() 我們用偽代碼還原一下執行棧中發生了什么?? // 第一次調用 foo ECStack = [functionContext, globalContext ] // 第二次調用 foo ECStack = [ functionContext – recursively(遞歸), functionContext, globalContext ]
我們看一個實際的例子
let a = "Hello World!"; function first() { console.log("Inside first function"); second(); console.log("Again inside first function"); } function second() { console.log("Inside second function"); } first(); console.log("Inside Global Execution Context");
首先執行這段代碼,解析器解析到了這段代碼,于是先創建了一個全局上下文,并把全局上下文壓入執行棧
ECStack = [ Global Context ]
然后解析器檢測到了 first(),開始調用first函數,于是創建了一個first函數上下文,并把這個函數向下文壓入到執行棧的頂部(一般執行棧的頂部都是正在運行的上下文,現在正在調用first函數,所以頂部就是他的上下文)
ECSstack= [ First Function Context-----(頂部是正在執行的上下文) Global Context ]
在first() 函數內部又調用了second()函數,于是JavaScript 引擎為second()函數創建了一個屬于他的執行上下文,并把它壓入執行棧的最頂部。(因為現在執行second()函數,所以他的執行上下文就在最頂部,因為first()函數沒有執行完所以他的執行上下文依然在執行棧的隊列中)
ECSstack = [ Cecond Function Context-----(頂部是正在執行的上下文) First Function Context Global Context ]
執行完second()函數之后,它的執行上下文會自動從執行棧彈出,并且控制流程執行下一個執行上下文,即 first() 函數的執行上下文。
ECSstack= [ First Function Context-----(頂部是正在執行的上下文) Global Context ]
當 first() 執行完畢,它的執行上下文自動從棧彈出,控制流程按順序到達全局執行上下文。一旦所有代碼執行完畢,JavaScript 引擎從當前棧中移除全局執行上下文。
ECStack = [ Global Context ]
6:JavaScript 引擎是怎么創建執行上下文?
創建執行上下文有兩個階段:1>:創建階段 和 2>:執行階段。
1>:創建階段--(The Creation Phase)
在創建階段會發生三件事
ExecutionContext = { ThisBinding =, // this綁定 LexicalEnvironment = { ... }, // 詞法環境 VariableEnvironment = { ... }, // 變量環境 }
This 綁定。
在全局執行上下文中,this 的值指向全局對象。(在瀏覽器中,this引用 Window 對象)。在函數執行上下文中,this 的值取決于該函數是如何被調用的。如果它被一個引用對象調用,那么 this 會被設置成那個對象,否則 this 的值被設置為全局對象或者 undefined(在嚴格模式下)。例如:
let foo = { baz: function() { console.log(this); } } foo.baz(); // "this" 引用 "foo", 因為 "baz" 被對象 "foo" 調用 let bar = foo.baz; bar(); // "this" 指向全局 window 對象,因為沒有指定引用對象
創建詞法環境組件。
詞法環境是一種規范類型,基于 ECMAScript 代碼的詞法嵌套結構來定義標識符和具體變量和函數的關聯。一個詞法環境由環境記錄器和一個可能的引用外部詞法環境的空值組成。有點沒明白
簡單來說詞法環境是一種定義標識符以及變量的嵌套結構。(這里的標識符指的是變量/函數的名字,而變量是對實際對象[包含函數類型對象]或原始數據的引用)。
在詞法環境的內部有兩個部件組成:
1:環境記錄器:是存儲變量和函數聲明的實際位置。:2: 外部環境的引用:意味著它可以訪問其父級詞法環境(作用域)。
詞法環境有兩種類型:
1:全局環境:(在全局執行上下文中)是沒有外部環境引用的詞法環境。全局環境的外部環境引用是 null。它擁有內建的
Object/Array/等、在環境記錄器內的原型函數(關聯全局對象,比如 window 對象)還有任何用戶定義的全局變量,并且
this的值指向全局對象。2:函數環境:函數內部用戶定義的變量存儲在環境記錄器中。并且引用的外部環境可能是全局環境,或者任何包含此內部函數的外部函數。
環境記錄器也有兩種類型:
1:聲明式環境記錄器存儲變量、函數和參數。2:對象環境記錄器用來定義出現在全局上下文中的變量和函數的關系。
簡而言之,
環境記錄器在全局環境中,環境記錄器是對象環境記錄器。 在函數環境中,環境記錄器是聲明式環境記錄器。
注意
函數環境,聲明式環境記錄器還包含了一個傳遞給函數的 arguments 對象(此對象存儲索引和參數的映射和傳遞給函數的參數的length)
抽象地講,詞法環境在偽代碼中看起來像這樣:
GlobalExectionContext = { // 全局執行上下文 LexicalEnvironment: { // 詞法環境組件 EnvironmentRecord: { // 環境記錄器 ---對象環境記錄器 Type: "Object", // 在這里綁定標識符 } outer:// 外部環境引用, 是沒有外部環境引用的詞法環境。全局環境的外部環境引用是 null。 } } FunctionExectionContext = { // 函數執行上下文 LexicalEnvironment: { // 詞法環境組件 EnvironmentRecord: { // 環境記錄器 ---聲明式環境記錄器 Type: "Declarative", // 在這里綁定標識符 } outer: //外部環境引用 函數內部用戶定義的變量存儲在環境記錄器中。并且引用的外部環境可能是全局環境,或者任何包含此內部函數的外部函數。 } }
創建變量環境組件。
變量環境也是一個詞法環境。所以它有著上面定義的詞法環境的所有屬性,其環境記錄器持有變量聲明語句在執行上下文中創建的綁定關系。
在 ES6 中,詞法環境組件和變量環境組件的一個不同就是前者被用來存儲函數聲明和變量(let 和 const)綁定,而后者只用來存儲 var 變量綁定。
來個栗子
let a = 20; const b = 30; var c; function multiply(e, f) { var g = 20; return e * f * g; } c = multiply(20, 30);
執行上下文用偽函數這么表示
// 全局執行上下文 GlobalExectionContext = { 1:ThisBinding:, //this綁定 2: LexicalEnvironment: { // 詞法環境 --全局的詞法環境 EnvironmentRecord: { //環境記錄器 Type: "Object", // 在這里綁定標識符 a: < uninitialized >, // 變量a的綁定(let) b: < uninitialized >, // 變量b 的綁定(const) multiply: < func > // 函數聲明 } outer: // 外部環境的引用nul }, 3: VariableEnvironment: { // 變量環境 --全局的詞法環境 EnvironmentRecord: { //環境記錄器 Type: "Object", // 在這里綁定標識符 c: undefined, // 變量c 的綁定(var) } outer: // 外部環境的引用nul } } // 函數的執行上下文-----(只有遇到調用函數 multiply 時,函數執行上下文才會被創建) FunctionExectionContext = { 1:ThisBinding: , // this 綁定 2:LexicalEnvironment: { //詞法環境 --函數的詞法環境 EnvironmentRecord: { // 環境記錄器 Type: "Declarative", // 在這里綁定標識符 Arguments: {0: 20, 1: 30, length: 2}, // 聲明式環境記錄器還包含了一個傳遞給函數的 arguments 對象(此對象存儲函數參數鍵值對和傳遞給函數的參數的length)。 }, outer: // 外部環境的引用是全局環境 }, 3:VariableEnvironment: { //變量環境 EnvironmentRecord: { // 環境記錄器 Type: "Declarative", // 在這里綁定標識符 g: undefined // 變量g的綁定(var) }, outer: // 外部環境的引用是全局環境 } }
可能你已經注意到 let 和 const 定義的變量并沒有關聯任何值,但 var 定義的變量被設成了 undefined。
這是因為在創建階段時,引擎檢查代碼找出變量和函數聲明,雖然函數聲明完全存儲在環境中,但是變量最初設置為 undefined(var
情況下),或者未初始化(let 和 const 情況下)。 這就是為什么你可以在聲明之前訪問 var 定義的變量(雖然是
undefined),但是在聲明之前訪問 let 和 const 的變量會得到一個引用錯誤。 這就是我們說的變量聲明提升。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/98291.html
摘要:什么是中的調用棧調用棧就像是程序當前執行的日志。當函數執行結束時,將從調用棧中出去。了解全局和局部執行上下文是掌握作用域和閉包的關鍵。總結引擎創建執行上下文,全局存儲器和調用棧。 原文作者:Valentino 原文鏈接:https://www.valentinog.com/blog/js-execution-context-call-stack 什么是Javascript中的執行上下文...
摘要:深入系列第七篇,結合之前所講的四篇文章,以權威指南的為例,具體講解當函數執行的時候,執行上下文棧變量對象作用域鏈是如何變化的。前言在深入之執行上下文棧中講到,當代碼執行一段可執行代碼時,會創建對應的執行上下文。 JavaScript深入系列第七篇,結合之前所講的四篇文章,以權威指南的demo為例,具體講解當函數執行的時候,執行上下文棧、變量對象、作用域鏈是如何變化的。 前言 在《Jav...
摘要:深入系列第三篇,講解執行上下文棧的是如何執行的,也回答了第二篇中的略難的思考題。 JavaScript深入系列第三篇,講解執行上下文棧的是如何執行的,也回答了第二篇中的略難的思考題。 順序執行? 如果要問到 JavaScript 代碼執行順序的話,想必寫過 JavaScript 的開發者都會有個直觀的印象,那就是順序執行,畢竟: var foo = function () { ...
摘要:執行上下文當代碼運行的時候,運行代碼的環境形成了執行上下文,執行上下文決定代碼可以訪問哪些變量函數對象等。我們將執行上下文簡單視為運行當前代碼的,我們知道作用域分為和。完成后,其執行堆棧將從堆棧中刪除,將控制權交給全局執行上下文。 我們通常將 JavaScript 歸類為動態或解釋執行語言,但實際上它也是一門編譯語言,它有自己的編譯器形式,運行在 JavaScript 引擎中。 每個 ...
摘要:深入系列第八篇,介紹理論上的閉包和實踐上的閉包,以及從作用域鏈的角度解析經典的閉包題。定義對閉包的定義為閉包是指那些能夠訪問自由變量的函數。 JavaScript深入系列第八篇,介紹理論上的閉包和實踐上的閉包,以及從作用域鏈的角度解析經典的閉包題。 定義 MDN 對閉包的定義為: 閉包是指那些能夠訪問自由變量的函數。 那什么是自由變量呢? 自由變量是指在函數中使用的,但既不是函數參數也...
摘要:執行上下文和執行棧是中關鍵概念之一,是難點之一。理解執行上下文和執行棧同樣有助于理解其他的概念如提升機制作用域和閉包等。函數執行完成,函數的執行上下文出棧,并且被銷毀。 前言 如果你是一名 JavaScript 開發者,或者想要成為一名 JavaScript 開發者,那么你必須知道 JavaScript 程序內部的執行機制。執行上下文和執行棧是JavaScript中關鍵概念之一,是Ja...
閱讀 1597·2023-04-25 14:12
閱讀 1070·2021-08-27 16:24
閱讀 2533·2019-08-30 15:44
閱讀 2912·2019-08-30 13:16
閱讀 1665·2019-08-29 14:10
閱讀 966·2019-08-29 13:54
閱讀 1296·2019-08-29 13:09
閱讀 1803·2019-08-26 18:37