JavaScript是如何工做的：引擎，運行時和調用堆棧的概述！

阿里雲最近在作活動，低至2折，有興趣能夠看看：
https://promotion.aliyun.com/...

---

爲了保證的可讀性，本文采用意譯而非直譯。

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

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等着你！

如 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...

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

交流

乾貨系列文章彙總以下，以爲不錯點個Star，歡迎 加羣 互相學習。

https://github.com/qq44924588...

我是小智，公衆號「大遷世界」做者，對前端技術保持學習愛好者。我會常常分享本身所學所看的乾貨，在進階的路上，共勉！

關注公衆號，後臺回覆福利，便可看到福利，你懂的。