JavaScript進階-內存機制(表情包初探)

前言

距離上一次更《JavaScript 進階系列》的文章已經一個月了, 抱歉請原諒我最近工做是有那麼點小忙😅, 並且主要是去寫 《全網最詳bpmn.js教材》 系列了.

並非我三心二意哈😳, 而是想着本身在搗鼓bpmn.js這東西的時候累死累活的, 因此搗鼓完以後就急切的想出一系列教材來下降你們的脫髮率...

這周開始, 更新繼續啦😄.

那麼仍是說說本章的內容吧. 其實看了標題你們也都知道我今天要說的是關於JavaScript中的內存機制了.

在寫以前我也看了不少關於內存機制比較好的文章, 發現其實瞭解內存機制主要是爲了幫咱們更好的瞭解JavaScript中的垃圾回收機制以及避免內存泄露等問題.

內存回收

咱們已經知道在JS中無論是全局變量仍是局部變量它們都存儲內存之中, 那麼這些變量在使用完以後, 是停留在它原來的地方仍是去了什麼別的地方呢🤔️?

若是說這些變量咱們已經再也不須要它了, 那咱們是否是能夠稱它們爲「垃圾」🤔️?

既然都已是「垃圾」了, 那麼是否是應該被清理掉🤔️?

清理它們的又是誰呢🤔️?

是用什麼方式清理呢🤔️?

抱歉...一不當心來了幾個靈魂拷問...

下面👇就爲你們一一解答哈😄.

其實在JS中是有一個自動垃圾收集機制的, 垃圾收集器(就像是咱們的保潔阿姨)會每隔一段時間就執行一次釋放操做, 去清理掉那些再也不使用的值, 來釋放它們佔用的內存.

銷燬局部變量和全局變量

首先局部變量和全局變量的清除有什麼不一樣呢?

1. 局部變量的銷燬

對於局部變量, 因爲它們是存在於函數中的, 那麼當這個函數執行完了以後, 它裏面的變量會被GC(垃圾收集)掉嗎🤔️?

不少教材中說的是:

垃圾收集器很容易作出判斷並回收.

確實, 這裏還真不是所有被清理掉, 仍是得看狀況.

好比閉包中的變量並不會隨着函數的執行完畢而被清除掉，反而會一直保留着，除非這個閉包被清除-也就是閉包中涉及的變量再也沒有被別的函數引用到.

2. 全局變量的銷燬

全局變量所存在的做用域太過普遍了, 何時須要自動釋放內存空間就很難判斷. 具體要不要回收仍是得看後面的垃圾回收機制, 因此才說要避免使用全局變量.

---

V8引擎的內存機制

首先你們要知道一點, 咱們常說的引擎, 它在使用的時候實際上是會使用系統的內存的.

對於像Java/Go這樣的後端語言, 在使用內存的時候是沒有什麼限制的.

可是對於咱們V8引擎來講(應該都知道V8引擎是一種JS引擎的實現), 它只能使用系統的一部份內存.

查看了一下資料:

• 64位系統下能使用約1.4GB;
• 32位系統下能使用約0.7GB.

在咱們前端看來好像已經不少了, 夠用了, 可是別忘了node.js這位「後端大哥」.

想一想要是它遇到了一個很大的文件, 好比2G的文件, 那麼它就沒法將其所有讀入內存且進行其餘的操做.

再來想一想咱們JS中的存儲, 分爲棧存儲和堆存儲.

1. 對於棧內存, 當ESP指針(你只須要知道它是棧指針)下移，也就是上下文切換以後，棧頂的空間會自動被回收.
2. 而對象的存儲是經過堆來進行分配的, 當在構建一個對象且進行賦值操做的時候, JS會將相應的內存分配到堆上. 因此每建立一個對象以後, 堆就會大一點.

那麼前面咱們也說了, V8引擎只能使用系統的一部份內存, 你的堆可能會不停的增大, 直到大小達到了V8引擎的內存上限爲止.

但是V8引擎爲何要給它設置一個內存的上限呢? 若是沒有上限或者上限很大, 那麼不是可以幹更多的事啦🤔️?

其實這個還真不怪V8, 主要緣由是兩個你們都常常聽到的詞:

• JS的單線程執行機制
• JS垃圾回收機制的限制

爲何說這兩個是限制內存上限的緣由呢🤔️?

在JS中, 因爲它是單線程運行的, 也就是一次只能作一件事, 那麼意味着一旦進入了垃圾回收階段, 其它的運行邏輯都得暫停了, 得等它過了這個階段才繼續執行.

可是好巧不巧的是, 垃圾回收是一件很是耗時的事情, 以 1.5GB 的垃圾回收堆內存爲例，V8 作一次小的垃圾回收須要50ms 以上，作一次非增量式的垃圾回收甚至要 1s 以上.

因此如果垃圾回收時常太久的話, JS代碼會一直沒有響應, 形成了應用卡頓, 其中的壞處我就不用多說了吧.

就這樣, V8乾脆給它限制了堆內存大小, 這樣就算你到頂了也不會說太卡, 並且其實大部分狀況也不會說有操做幾個G的狀況, 所以這也是V8的一種權衡.

這個限制是不可修改的嗎🤔️?

並非的, 你能夠經過執行如下命令來修改它:

// 這是調整老生代這部分的內存，單位是MB。後面會詳細介紹新生代和老生代內存
node --max-old-space-size=2048 xxx.js 

// 這是調整新生代這部分的內存，單位是 KB。
node --max-new-space-size=2048 xxx.js
複製代碼

以前我在用Angular打包項目的時候就遇到過頻繁報內存溢出：FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory。而且打包速度至關慢，估計項目過大了.

解決辦法就是:

定義在項目根目錄node_modeles文件夾下的.bin目錄裏面，.bin目錄下咱們能找到一個叫ng的文件，在該文件的首行寫上#!/usr/bin/env node --max_old_space_size=4096，這樣也就能夠解除v8對node的內存使用限制了。

固然若是你是用vue和react開發的話就沒這麼麻煩了, 具體能夠看這篇文章:

《nodejs 前端項目編譯時內存溢出問題的緣由及解決方案》

---

堆內存的分代管理

V8引擎對堆內存中的JS對象進行了分代管理, 也就是分爲 新生代 和 老生代.

首先讓咱們來了解如下幾個知識點:

• 新生代 就是臨時分配的內存，存活時間短, 如臨時變量、字符串等;
• 老生代 是常駐內存，存活的時間長, 如主控制器、服務器對象等;
• V8的堆內存, 就是兩個內存只和.

就像下面的這張圖同樣:

新生代內存的回收

其實也像圖裏畫的同樣, 新生代的默認內存限制很小:

• 64位系統下爲32MB;
• 32位系統下爲16MB.

確實是夠小的啦, 主要緣由是新生代中的變量存活時間短，來了立刻就走，不容易產生太大的內存負擔，所以能夠將它設的足夠小.

新生代內存結構

新生代內存會被分爲兩個部分:

一塊叫作From, 另外一塊叫作To. (別的教材中是這麼命名的, 後來我去找尋緣由, 發現大概是由於在V8的源碼-內存管理中有from_space_和to_space_這兩個東西吧)

• From表示正在使用的內存;
• To表示目前閒置的內存.

Scavenge算法

上面已經介紹了新生代內存的結構, 下面來講說它具體是如何進行垃圾回收的.

當進行垃圾回收的時候, 會通過一下幾個步驟:

1. V8將From部分的對象所有檢查一遍;
2. 檢查出如果 存活對象 則複製到To內存中, 若不是則直接回收;
3. 複製到To內存中是按照順序從頭放置的;
4. 當From中全部的存活對象所有複製完畢以後, From和To就會 對調 , 也就是From被閒置, To在使用;
5. 如此循環.

一張圖方便你理解🤔:

不就是個清理垃圾的動做嗎? 爲何V8要整的這麼複雜啊, 又是遍歷又是複製的.

並且爲何還要在To內存中按照順序從頭放置呢🤔️?

其實, 它這樣作是有必定好處的, 首先讓咱們來看看下面這張圖:

在上圖中, 黃色的部分是待分配的內存, 而藍色的小方塊就是存活對象.

看起來存活對象很是的散亂, 使得空間變得零零散散, 而且堆內存又是連續分配的, 如果碰到稍微大點的對象的話都沒有辦法進行空間分配了.

堆包含一個鏈表來維護已用和空閒的內存塊。在堆上新分配（用 new 或者 malloc）內存是從空閒的內存塊中找到一些知足要求的合適塊。因此可能讓人以爲只要有不少不連續的零散的小區域，只要總數達到申請的內存塊，就能夠分配。

但事實上是不行的，這又讓人以爲是否是零散的內存塊不能鏈接成一個大的空間，而必需要一整塊連續的內存空間才能申請成功.

(原文連接：blog.csdn.net/jin13277480…)

而這種零散的空間也有一個名字, 叫作 內存碎片.

所以將其按照順序從頭放置也是爲了解決 內存碎片 的問題, 在一頓複製以後, To內存會被排列的整整齊齊的:

整頓以後就大大方便了後續連續空間的分配.

上面👆說的這種新生代垃圾回收算法也被叫作 Scavenge算法 (scavenge的本意就是回收).

因此這個Scavenge算法不只僅是將非存活對象給回收了, 還須要對內存空間作整頓.

就像是咱們日常打掃房間, 不只僅是將不要的垃圾清理掉, 還順便把房間內的東西給放整齊了😊.

老生代內存的回收

若是新生代中的變量通過屢次回收以後依然存在的話, 它就會發生「晉升」, 被放入老生代內存中.

產生晉升的狀況:

• 已經經歷過一次Scavenge回收;
• To(閒置內存)空間的內存不足75%.

經過上面👆的介紹咱們已經知道, 老生代內存的空間會比新生代的大了不少, 並且老生代累計的變量空間通常都是很大的.

所以老生代的垃圾回收就不能用Scavenge算法了, 一是會浪費一半的空間, 二對龐大的內存空間進行復制自己就是個「很重的體力活」.

標記清除

因此對於老生代的垃圾回收乾脆粗暴點吧, 採用標記清除的方式進行回收.

標記清除主要是通過如下幾個過程:

1. 遍歷堆中的全部對象, 給它們作上標記;
2. 以後對於代碼環境中使用的變量和被強引用的變量取消標記(被標記的都是垃圾);
3. 把依然被標記的變量當成垃圾給清除掉, 進行空間的回收;

固然, 和新生代同樣, 在清理了以後, 還要整理內存碎片, 固然它的整理辦法就是在清理階段結束後把存活對象所有往一端靠攏.

因此總的來講, 對於老生代內存的回收主要就是通過:

• 標記清除階段, 留下存活對象;
• 整理階段, 把存活對象往一邊靠攏.

所以, 對於如今的主流瀏覽器來講, 只要切斷對象與根部的關係, 就能夠將對象進行回收.

併發標記

在上面咱們已經介紹過了V8在進行垃圾回收的時候, 不可避免地會阻塞業務邏輯的執行, 特別若是是老生代垃圾回收的任務比較繁重的時候, 會很耗時嚴重影響應用的性能.

爲優化解決此問題, V8官方在2018年推出了名爲增量標記的技術.

總的來講該技術的做用就是將本來一口氣完成的標記任務分爲了不少小的部分去完成, 每完成一個小任務就停一會, 讓js邏輯執行一會, 而後再繼續執行下面的部分.

在 GC 掃描和標記活動對象時，它容許 JavaScript 應用程序繼續運行

其實它內部並無上面👆說的這麼簡單, 仍是有不少實現機制的, 具體的能夠看這裏:

《引擎V8推出「併發標記」，可節省60%-70%的GC時間》

在經過增量標記後, 垃圾回收過程對JS應用的阻塞時間減小到原來了1 / 6, 能夠說這優化至關大了啊.

後語

這一章節就主要介紹到這裏, 關於更多內存泄露以及避免內存泄露的內存我想仍是放到下一章來說吧.

此次也是我第一次在文章中使用表情包, 以前看到不少優秀的做者喜歡這樣用, 而後今天嘗試了一下...

發現停不下來了, 越用越興奮😂.

確實有些表情能很好的表達出做者想要表達的意思, 還能搏看官們一笑😄, 何樂而不爲呢, 哈哈.

參考文章:

• 《神三元-V8 引擎垃圾內存回收原理解析》
• 《木易楊-JavaScript深刻之帶你走進內存機制》
• 《nodejs 前端項目編譯時內存溢出問題的緣由及解決方案》
• 《引擎V8推出「併發標記」，可節省60%-70%的GC時間》
• segmentfault.com/q/101000000…