JavaScript是如何工作的:引擎,執行時和呼叫堆疊的概述!

前端小智發表於2018-12-12

本文是旨在深入研究JavaScript及其實際工作原理的系列文章中的第一篇:我們認為通過了解JavaScript的構建塊以及它們是如何工作的,將能夠編寫更好的程式碼和應用程式。我們還將分享構建 SeStHealsStad 時使用的一些經驗法則,這是一個輕量級的 JavaScript 應用程式,必須保持健壯和高效能以保持競爭力。

GitHut 統計 資料所示,在GitHub中的活動儲存庫和總推送方面,JavaScript處於頂部。它也不落後於其他類別。

圖片描述

如果專案越來越依賴於 JavaScript,這意味著開發人員必須利用語言和生態系統提供的所有內容,對內部進行更深入的瞭解,以便構建出色的軟體。

事實證明,有很多開發人員每天都在使用JavaScript,但卻不知道背後發生了什麼。

概述

幾乎每個人都已經聽說過 V8 引擎,大多數人都知道 JavaScript 是單執行緒的,或者它使用的是回撥佇列。

在本文中,我們將詳細介紹這些概念,並解釋 JavaScrip 實際如何執行。通過了解這些細節,你將能夠適當地利用所提供的 API 來編寫更好的、非阻塞的應用程式。

如果您對JavaScript還比較陌生,那麼本文將幫助您理解為什麼JavaScript與其他語言相比如此“怪異”。

如果你是一個有經驗的JavaScript開發人員,希望它能讓您對每天使用的JavaScript執行時的實際工作方式有一些新的見解。

JavaScript引擎

JavaScript引擎的一個流行示例是Google的V8引擎。例如,在Chrome和Node.js中使用V8引擎,下面是一個非常簡化的檢視:

圖片描述

V8引擎由兩個主要部件組成:

  • emory Heap(記憶體堆) — 記憶體分配地址的地方
  • Call Stack(呼叫堆疊) — 程式碼執行的地方

Runtime(執行時)

有些瀏覽器的 API 經常被使用到(比如說:setTimeout),但是,這些 API 卻不是引擎提供的。那麼,他們是從哪兒來的呢?事實上這裡面實際情況有點複雜。

圖片描述

所以說我們還有很多引擎之外的 API,我們把這些稱為瀏覽器提供 API 稱為 Web API,比如說 DOM、AJAX、setTimeout等等。

然後我們還擁有如此流行的事件迴圈和回撥佇列。

呼叫棧

JavaScript是一種單執行緒程式語言,這意味著它只有一個呼叫堆疊。因此,它一次只能做一件事。

呼叫棧是一種資料結構,它記錄了我們在程式中的位置。如果我們執行到一個函式,它就會將其放置到棧頂,當從這個函式返回的時候,就會將這個函式從棧頂彈出,這就是呼叫棧做的事情。

來個栗子:

圖片描述

當程式開始執行的時候,呼叫棧是空的,然後,步驟如下:

圖片描述

每一個進入呼叫棧的都稱為呼叫幀。

這能清楚的知道當異常發生的時候堆疊追蹤是怎麼被構造的,堆疊的狀態是如何的,讓我們看一下下面的程式碼:

圖片描述

如果這發生在 Chrome 裡(假設這段程式碼實在一個名為 foo.js 的檔案中),那麼將會生成以下的堆疊追蹤:

圖片描述

"堆疊溢位",當你達到呼叫棧最大的大小的時候就會發生這種情況,而且這相當容易發生,特別是在你寫遞迴的時候卻沒有全方位的測試它。我們來看看下面的程式碼:

圖片描述

當引擎開始執行這段程式碼時,它首先呼叫函式“foo”。然而,這個函式是遞迴的,並且在沒有任何終止條件的情況下開始呼叫自己。因此,在執行的每一步中,相同的函式都會被一次又一次地新增到呼叫堆疊中,如下所示:

圖片描述

然而,在某些時候,呼叫堆疊中的函式呼叫數量超過了呼叫堆疊的實際大小,瀏覽器決定採取行動,丟擲一個錯誤,它可能是這樣的:

圖片描述

在單個執行緒上執行程式碼很容易,因為你不必處理在多執行緒環境中出現的複雜場景——例如死鎖。
但是在一個執行緒上執行也非常有限制,由於 JavaScript 只有一個呼叫堆疊,當某段程式碼執行變慢時會發生什麼?

併發與事件迴圈

當呼叫堆疊中的函式呼叫需要花費大量時間來處理時會發生什麼情況? 例如,假設你希望在瀏覽器中使用JavaScript進行一些複雜的影象轉換。

你可能會問-為什麼這是一個問題?問題是,當呼叫堆疊有函式要執行時,瀏覽器實際上不能做任何其他事情——它被阻塞了,這意味著瀏覽器不能呈現,它不能執行任何其他程式碼,它只是卡住了,如果你想在應用中使用流暢的頁面效果,這就會產生問題。

而且這不是唯一的問題,一旦你的瀏覽器開始處理呼叫棧中的眾多工,它可能會停止響應相當長一段時間。大多數瀏覽器都會這麼做,報一個錯誤,詢問你是否想終止 web 頁面。

圖片描述

這並不是最好的使用者體驗,不是嗎?

那麼,我們怎樣才能在不阻塞UI和不使瀏覽器失去響應的情況下執行大量程式碼呢?解決方案是非同步回撥。

這個在下一篇說明,我儘快把原作者的內容整理好!

程式碼部署後可能存在的BUG沒法實時知道,事後為了解決這些BUG,花了大量的時間進行log 除錯,這邊順便給大家推薦一個好用的BUG監控工具 Fundebug

原文:https://blog.sessionstack.com...

你的點贊是我持續分享好東西的動力,歡迎點贊!

歡迎加入前端大家庭,裡面會經常分享一些技術資源。

圖片描述

相關文章