聊聊V8的記憶體管理與垃圾回收演算法

這篇文章帶大家了解V8引擎的記憶體管理與垃圾回收演算法，希望對大家有幫助！

眾所周知，JS是自動管理垃圾回收的，開發者不需要關心記憶體的分配與回收。而且垃圾回收機制在前端面試也是常考的部分。本文主要講解V8的分代垃圾回收演算法，希望閱讀本文後的夥伴能夠對V8垃圾回收機制有個痛徹（哈哈，是痛徹！！！）的了解，文章主要涵蓋如下內容：

• V8的記憶體限制與解決方案
• 新生代記憶體物件的Scavenge演算法
• 基於可達性分析演算法標記存活物件的邏輯以及最佳化手段
• 新生代記憶體物件的晉升條件、
• Scavenge演算法的深度/廣度優先差異
• 跨代記憶體的的寫入屏障
• 老生代記憶體物件的標記清除/整理演算法
• GC的STW原因及最佳化策略

V8的記憶體限制與解決方法

V8最初為瀏覽器設計，遇到大內存使用的場景較少，在設計上預設對內存使用有限制，只允許使用部分內存，64位元系統可允許使用內存約1.4g，32位元系統約0.7g。如下程式碼所示，在Node中查看所依賴的V8引擎的記憶體限制方法：

process.memoryUsage();

// 返回内存的使用量，单位字节
{
  rss: 22953984,
  // 申请的总的堆内存
  heapTotal: 9682944,
  // 已使用的堆内存
  heapUsed: 5290344,
  external: 9388
}

#V8限制記憶體使用大小還有另一個重要原因，堆記憶體過大時V8執行垃圾回收的時間較長（1.5g要50ms），做非增量式的垃圾回收要更久（1.5g要1s）。在後續講解了V8的垃圾回收機制後相信大家更能感同身受。

雖然V8引擎對記憶體使用做了限制，但是同樣暴露修改記憶體限制的方法，就是啟動V8引擎時加入相關參數，下面程式碼示範在Node中修改依賴的V8引擎記憶體限制：

# 更改老生代的内存限制，单位mb
node --max-old-space-size=2048 index.js

# 更改新生代的内存限制，单位mb
node --max-semi-space-size=1024=64 index.js

這裡需要注意的是更改的新生代的記憶體的語法已經更改為上述的寫法，且單位也由kb變成了mb，舊的寫法是node --max-new-space-size，可以透過下方指令查詢目前Node環境修改新生代記憶體的語法:

node --v8-options | grep max

#V8垃圾回收策略

在引擎的垃圾自動在回收機制的歷史演變中，人們發現是沒有一種通用的可以解決任何場景下垃圾回收的演算法的。因此現代垃圾回收演算法根據物件的存活時間將記憶體垃圾進行分代，分代垃圾回收演算法就是對不同類別的記憶體垃圾實行不同的回收演算法。

V8將記憶體分成新生代與老生代兩種：

• 新生代記憶體中的物件存活時間較短
• 老生代記憶體中代物件存活時間較長或是常駐記憶體

新生代記憶體存放在新生代記憶體空間（semispace ）中，老生代記憶體存放在老生代記憶體空間（oldspace）,如下圖所示：

• 新生代記憶體採用Scavenge演算法
• 老生代記憶體採用Mark-Sweep和Mark-Compact演算法

下面我們來看看Scavenge的演算法邏輯吧！

Scavenge演算法

對於新生代記憶體的記憶體回收採用Scavenge演算法，Scavenge的具體實作採用的是Cheney演算法。 Cheney演算法是將新生代記憶體空間一分為二，一個空間處於使用狀態（FromSpace），一個空間處於空閒狀態（稱為ToSpace） 。

在内存开始分配时，首先在FromSpace中进行分配，垃圾回收机制执行时会检查FromSpace中的存活对象，存活对象会被会被复制到ToSpace，非存活对象所占用的空间将被释放，复制完成后FromSpace和ToSpace的角色将翻转。当一个对象多次复制后依然处于存活状态，则认为其是长期存活对象，此时将发生晋升，然后该对象被移动到老生代空间oldSpace中，采用新的算法进行管理。

Scavenge算法其实就是在两个空间内来回复制存活对象，是典型的空间换时间做法，所以非常适合新生代内存，因为仅复制存活的对象且新生代内存中存活对象是占少数的。但是有如下几个重要问题需要考虑：

• 引用避免重复拷贝

假设存在三个对象temp1、temp2、temp3，其中temp2、temp3都引用了temp1，js代码示例如下：

var temp2 = {
  ref: temp1,
}

var temp3 = {
  ref: temp1,
}

var temp1 = {}

从FromSpace中拷贝temp2到ToSpace中时，发现引用了temp1，便把temp1也拷贝到ToSpace，是一个递归的过程。但是在拷贝temp3时发现也引用了temp1，此时再把temp1拷贝过去则重复了。

要避免重复拷贝，做法是拷贝时给对象添加一个标记visited表示该节点已被访问过，后续通过visited属性判断是否拷贝对象。

• 拷贝后保持正确的引用关系

还是上述引用关系，由于temp1不需要重复拷贝，temp3被拷贝到ToSpace之后不知道temp1对象在ToSpace中的内存地址。

做法是temp1被拷贝过去后该对象节点上会生成新的field属性指向新的内存空间地址，同时更新到旧内存对象的forwarding属性上，因此temp3就可以通过旧temp1的forwarding属性找到在ToSpace中的引用地址了。

内存对象同时存在于新生代和老生代之后，也带来了问题：

• 内存对象跨代（跨空间）后如何标记

const temp1 = {}

const temp2 = {
  ref: temp1,
}

比如上述代码中的两个对象temp1和temp2都存在于新生代，其中temp2引用了temp1。假设在经过GC之后temp2晋升到了老生代，那么在下次GC的标记阶段，如何判断temp1是否是存活对象呢？

在基于可达性分析算法中要知道temp1是否存活，就必须要知道是否有根对象引用引用了temp1对象。如此的话，年轻代的GC就要遍历所有的老生代对象判断是否有根引用对象引用了temp1对象，如此的话分代算法就没有意义了。

解决版本就是维护一个记录所有的跨代引用的记录集，它是写缓冲区的一个列表。只要有老生代中的内存对象指向了新生代内存对象时，就将老生代中该对象的内存引用记录到记录集中。由于这种情况一般发生在对象写的操作，顾称此为写屏障，还一种可能的情况就是发生在晋升时。记录集的维护只要关心对象的写操作和晋升操作即可。此是又带来了另一个问题：

• 每次写操作时维护记录集的额外开销

优化的手段是在一些Crankshaft操作中是不需要写屏障的，还有就是栈上内存对象的写操作是不需要写屏障的。还有一些，更多的手段就不在这里过多讨论。

• 缓解Scavenge算法内存利用率不高问题

新生代内存中存活对象占比是相对较小的，因此可以在分配空间时，ToSpace可以分配的小一些。做法是将ToSpace空间分成S0和S1两部分，S0用作于ToSpace，S1与原FromSpace合并当成FromSpace。

Scavenge算法中深度/广度优先的区别

垃圾回收算法中，识别内存对象是否是垃圾的机制一般有两种：引用计数和基于可达性分析。

基於可達性分析，就是找出所有的根引用（例如全域變數等），遍歷所有根引用，遞歸根引用上的所有引用，凡是被遍歷到的都是存活物件並且被標記，此時空間中的其他記憶體物件都是死物件，由此建構了一個有向圖。

考慮到遞迴的限制問題，遞迴邏輯一般採用非遞迴實作，常見的有廣度優先和深度優先演算法。兩者的差異在於：

• 深度優先拷貝到ToSpace時改變了記憶體物件的排列順序，使得有引用關係的物件距離較近。原因是拷貝完自己之後直接拷貝自己引用的對象，因此相關的對象便在ToSpace中靠的較近
• #深度優先正好相反

因為CPU的快取策略，會在讀取記憶體物件時有很大機率把他後面的物件一起讀，目的是為了更快的命中快取。因為在程式碼開發期間很常見的場景就是obj1.obj2.obj3，此時CPU讀取obj1時如果把後面的obj2、 obj3一起讀的話，則很利於命中緩存。

所以深度優先的演算法更利於業務邏輯命中緩存，但是其實作需要依賴額外的堆疊輔助實作演算法，對記憶體空間有消耗。廣度優先則相反，無法提升快取命中，但是其實作可以利用指標巧妙的避開空間消耗，演算法的執行效率高。

新生代記憶體物件的晉升條件

新生代中的記憶體物件如果想晉升到老生代需要滿足以下幾個條件：

• #物件是否經歷過Scavenge回收
• ToSpace的記憶體使用佔比不能超過限制

Scavenge的GC的邏輯是，每次GC時給存活物件的age屬性 1，當再次GC的時候判斷age屬性即可。基本的晉升示意圖如下：

Scavenge演算法回收的原因在於：

存活物件較多導致複製效率低
• 浪費了一半的記憶體空間

老生代記憶體物件的回收演算法

標記清除（Mark-Sweep）和標記整理（Mark -Compact）結合的方式。標記清除分為兩部分：

標記階段
• 清除階段（如果是標記整理則是整理階段）

垃圾回收的全暫停

全暫停”，也就是常說的Stop The World，簡稱STW。對新生代記憶體的垃圾回收該行為對應用執行影響不大，但是老生代記憶體由於存活對象較多，所以老生代記憶體的垃圾回收造成的全停頓影響非常大。

增量標記、並發標記、並行標記、增量整理、並行清理、延遲清理等方式。

STW最佳化

GC 時主執行緒暫停的時間量。 STW所帶來的影響是無法接受的，因此V8也採取的許多優化手段。

• 並行GC

GC的過程需要做大量的事情從而在主執行緒上導致STW現象，並行GC的做法是開多個輔助執行緒分擔GC的事情。此做法依然無法避免STW現象的，但是可以減少STW的總時間，取決於開啟的輔助線程數量。

• 增量GC

#增量GC將GC工作拆分，並在主線程中歇的分步執行。此做法並不會減少GC的時間，相反會稍微花錢，但它同樣會減少GC的STW的總時間。

• 並發GC

#並發GC是指GC在後台運行，不再在主執行緒運行。此做法會避免STW現象。

• 空閒時間GC

#Chrome中動畫的渲染大約是60幀（每幀約16ms），如果當前渲染所花費時間每達到16.6ms，此時則有空閒時間做其他事情，例如部分GC任務。

減少垃圾回收的影響

#想要提高執行效率要盡量減少垃圾回收的執行與消耗：

• 慎把記憶體當作緩存，小心把物件當作緩存，要合理地限制過期時間和無限成長的問題，可以採用lru策略

• Node中避免使用記憶體儲存使用者會話，否則在記憶體中存放大量使用者會話物件導致老生代記憶體激增，影響清理效能進而影響應用程式執行效能和記憶體溢位。改進方式使用使用redis等。將快取轉移到外部的好處：

  • 減少常駐記憶體物件的數量，垃圾回收更有效率
  • 進程之間可以共享快取

更多node相關知識，請造訪：nodejs 教學！

以上是聊聊V8的記憶體管理與垃圾回收演算法的詳細內容。更多資訊請關注PHP中文網其他相關文章！