V8的垃圾回收機制與內(nèi)存限制

V8的內(nèi)存限制

在一般的后端開發(fā)語言中，在基本的內(nèi)存使用上沒有什么限制，然而在Node中通過JavaScript使用內(nèi)存時就會發(fā)現(xiàn)只能使用部分內(nèi)存（64位系統(tǒng)下約為1.4GB，32位系統(tǒng)下約為0.7GB），在這樣的限制下，將會導(dǎo)致Node無法直接操作大內(nèi)存對象，比如無法將一個2GB的文件讀入內(nèi)存中進行字符串分析處理。

造成這個問題的主要原因在于Node基于V8構(gòu)建，所以在Node中使用的JavaScript對象基本都是通過V8自己的方式來進行分配和管理的。V8的這套內(nèi)存管理機制在瀏覽器的應(yīng)用場景下使用起來綽綽有余，但在Node中，卻限制了開發(fā)者隨心使用大內(nèi)存的想法。

V8對象分配

在V8中所有的JavaScript對象都是通過堆來進行分配的，在Node中使用process.memoryUsage()能夠得到內(nèi)存的使用信息對象，其中heapTotal 和 heapUsed 代表 V8 的內(nèi)存使用情況，已申請的和已使用的。 external 代表 V8 管理的，綁定到 Javascript 的 C++ 對象的內(nèi)存使用情況。 rss 是駐留集大小, 是給這個進程分配了多少物理內(nèi)存（占總分配內(nèi)存的一部分），這些物理內(nèi)存中包含堆、代碼段、以及棧。

在當我們在代碼中聲明變量并賦值時，所使用對象的內(nèi)存就分配在堆中，如果已申請的堆空閑內(nèi)存不夠分配新的對象，將繼續(xù)申請堆內(nèi)存，直到堆的大小超過V8的限制為止。

V8為什么要限制堆的大小

表層原因是V8最初為瀏覽器而設(shè)計，不太可能遇到大量內(nèi)存的使用場景。深層原因是V8的垃圾回收機制的限制，按官方的說法，以1.5GB的垃圾回收堆為例，V8做一次小的垃圾回收需要50毫秒以上，做一次非增量式的垃圾回收甚至要1秒以上。這里的時間指的是在垃圾回收中引起JavaScript線程暫停執(zhí)行的時間。很明顯，這是無法接受的，因此直接限制了堆內(nèi)存的大小。

當然，這個限制也可以打開，Node在啟動時可以傳遞--max-old-space-size或 --max-new-space-size來調(diào)整內(nèi)存限制的大小

node --max-old-space-size=1700 test.js // 單位為MB 設(shè)置老生代內(nèi)存空間的最大值

node --max-new-space-size=1024 test.js // 單位為KB 設(shè)置新生代內(nèi)存空間的最大值

只能在初始化的時候設(shè)置，一旦生效就不能再動態(tài)改變。

V8的垃圾回收機制

在V8中，主要將內(nèi)存分為新生代和老生代兩代，新生代中的對象為存活時間較短的對象，老生代中的對象為存活時間較長或常駐內(nèi)存的對象。

V8的整體大小就是新生代所用內(nèi)存空間加上老生代的內(nèi)存空間，在64位系統(tǒng)中，老生代內(nèi)存為1400MB，新生代內(nèi)存為32MB，在32位系統(tǒng)中，則分別為700MB、16MB。又因為新生代內(nèi)存有2個，所以在64位系統(tǒng)中，V8堆內(nèi)存的最大值為1464MB，而在32位系統(tǒng)中則為732MB。

新生代：Scavenge算法

新生代中的對象主要通過Scavenge算法進行垃圾回收，它將新生代內(nèi)存一分為二，每一部分的空間成為semispace（半空間），在這兩個semispace中，只有一個處于使用中，成為From空間；另一個處于閑置狀態(tài)，稱為To空間。當我們分配對象時，先是在From空間中進行分配，當開始進行垃圾回收時，會檢查From空間中的存活對象，這些存活對象將被復(fù)制到To空間中，而非存活對象占用的空間將被釋放，完成賦值后，F(xiàn)rom空間和To空間的角色發(fā)生對換。

Scavenge是典型的犧牲空間換取時間的算法，但Scavenge由于只復(fù)制存活的對象，并且對于生命周期短的場景存活對象只占少部分，所以它在事件效率上有優(yōu)異的表現(xiàn)，而新生代中對象的生命周期較短，恰恰適合這個算法。

當一個對象經(jīng)過多次復(fù)制依然存活時，它將會被認為是生命周期較長的對象，這種對象隨后會被移動到老生代中，這個過程被稱為晉升。

對象晉升的條件主要有兩個，一個是是否經(jīng)歷過Scavenge回收，一個是To空間的內(nèi)存占用比超過限制。

對象從From空間中復(fù)制到To空間時：

第一種情況：檢查它的內(nèi)存地址來判斷這個對象是否已經(jīng)經(jīng)歷過一次Scavenge回收，是就直接復(fù)制到老生代空間中，沒有就復(fù)制到To空間。

第二種情況：判斷To空間中是否已經(jīng)使用超過了25%，如果超過了，則直接晉升到老生代空間中，否則就復(fù)制To空間。設(shè)置25%這個限制值的原因是當這次Scavenge回收完成后，這個To空間就將變成From空間，接下來的內(nèi)存分配會在這個空間中進行，如果占比較高，會影響后續(xù)的內(nèi)存分配。

老生代：Mark-Sweep & Mark-Compact

對于老生代存活對象占較大比重，那么繼續(xù)采用Scavenge算法復(fù)制存活對象將效率很低，而且Scavenge算法會浪費一半的空間。為此V8在老生代主要采用了Mark-Sweep & Mark-Compact相結(jié)合的方式進行垃圾回收。

Mark-Sweep是標記清除的意思，它分為標記和清除兩個階段，它會在標記階段遍歷堆中的所有對象，并標記活著的對象，在隨后的清除階段階段只清除沒有被標記的對象，可以看出，Scavenge中只復(fù)制活著的對象，而Mark-Sweep只清理死亡對象，活對象在新生代中只占較小部分，死對象在老生代中只占較小部分，這是在新老生代使用這兩種不同回收方式的原因。

Mark-Sweep最大的問題在于進行一次標記清楚回收后，內(nèi)存空間會出現(xiàn)不連續(xù)的狀態(tài)，下圖中黑色的部分就會死亡對象，清除之后就出現(xiàn)這種個問題，這種內(nèi)存碎片會對后續(xù)的內(nèi)存分配造成問題，因為很可能出現(xiàn)需要分配一個大對象的情況，這時所有的碎片空間都無法完成這次分配，就會提前觸發(fā)垃圾回收，而這次回收是不必要的。

mark-sweep.png

而Mark-Compact就是為了解決Mark-Sweep的內(nèi)存碎片問題，是指標記整理的意思，是在Mark-Sweep的基礎(chǔ)上演變而來的，他們的差別在于對象在標記死亡后，在整理的過程中，將活著的對象往一端移動，移動完成后，直接清理調(diào)邊界外的內(nèi)存。

mark-compact.png

在V8中這兩種回收策略是結(jié)合使用的，但是由于Mark-Compact需要移動對象，所以它的執(zhí)行速度不可能很快，所以在取舍上，V8主要使用Mark-Sweep，在空間不足以對新生代中晉升過來的對象進行分配時才使用Mark-Compact。

{{% notice info %}}
為了避免出現(xiàn)JavaScript應(yīng)用邏輯與垃圾回收器看到的不一致的情況，垃圾回收的3種基本算法都需要將應(yīng)用邏輯暫停下來，待執(zhí)行完垃圾回收后再恢復(fù)執(zhí)行應(yīng)用邏輯，這種行為被成為“全停頓”（stop-the-world）
{{% /notice %}}

在V8的分代式垃圾回收中，一次小垃圾回收只收集新生代，由于新生代默認配置得較小，且其中存活對象通常較少，所以即便它是全停頓的影響也不大， 但老生代通常配置得較大，且存活對象較多，全堆垃圾回收的標記、清理、整理等動作造成的停頓就比較可怕，需要設(shè)法改善。

為了降低這種停頓時間，V8先從標記階段入手，將原本要一口氣停頓完成的動作改為了增量標記（incremental marking），也就是拆分為許多小“步進”，每做完一次“步進”，就讓JavaScript應(yīng)用邏輯執(zhí)行一小會兒，垃圾回收與應(yīng)用邏輯交替執(zhí)行直到標記階段完成。

V8在經(jīng)過增量標記的改進后，垃圾回收的最大停頓時間可以減少到原本的1/6左右，V8后續(xù)還移入了延遲清理（lazy sweeping）和增量式整理（incremental compaction），讓清理和整理動作也變成增量式的，同時還計劃引入并行標記和并行清理，進一步利用多核性能降低每次停頓的時間。

{{% notice tip %}}
對于V8的垃圾回收特點和JavaScript在單線程上的執(zhí)行情況，垃圾回收是影響性能的因素之一，想要高性能的執(zhí)行效率，需要注意讓垃圾回收盡量收的進行，尤其是全堆垃圾回收。
{{% /notice %}}

高效使用內(nèi)存

作用域

函數(shù)在每次調(diào)用時會創(chuàng)建對應(yīng)的作用域，函數(shù)執(zhí)行結(jié)束后，該作用域?qū)N毀，同時作用域中聲明的局部變量分配在該作用域上，隨著作用域的銷毀而銷毀，只被局部變量引用的對象存活周期較短，在作用域釋放之后，局部變量就會失效，其引用的對象將會在下次垃圾回收時內(nèi)被釋放。

JavaScript在執(zhí)行時回去查找該變量定義在哪里，它最先查找的是當前作用域，如果在當前作用域中無法找到該變量的聲明，將會向上級的作用域里查找，直到查到為止。

變量的主動釋放

如果變量是全局變量，由于全局作用域需要直到進程退出才能釋放，此時將導(dǎo)致引用的對象常駐在老生代中，如果需要釋放常駐內(nèi)存的對象，可以使用delete操作來刪除引用關(guān)系，或者將變量重新賦值，讓舊的對象脫離引用關(guān)系，在接下來的老生代內(nèi)存清除和整理的過程中，會被回收釋放。

global.foo = 'abc';
delete global.foo;

// 或者重新賦值
global.foo = undefined // or null;

{{% notice tip %}}
同樣，如果在非全局作用域中，想要主動釋放變量引用的對象，也可以通過這樣的方式，雖然delete操作和重新賦值具有相同的效果，但是在V8中通過delete刪除對象的屬性有可能干擾V8的優(yōu)化，所以通過賦值方式解除引用更好。
{{% /notice %}}

閉包

在JavaScript中，實現(xiàn)外部作用域訪問內(nèi)部作用域中的變量的方法叫做閉包（closure），這得益于高階函數(shù)的特性，函數(shù)可以作為參數(shù)或者返回值。

雖說局部變量將會隨著作用域的銷毀而被回收，但是閉包返回的是一個匿名函數(shù)，這個函數(shù)中具備了訪問局部變量的條件，雖然在后續(xù)的執(zhí)行中，外部作用域還是無法直接返回局部變量，但是若要訪問它，只要通過這個中間函數(shù)稍作周轉(zhuǎn)即可。

閉包是JavaScript的高級特性，利用它可以產(chǎn)生很多巧妙的效果，它的問題在于，一旦有變量引用這個中間函數(shù)，這個中間函數(shù)就不會被釋放，同時也會使原始的作用域不會得到釋放，作用域中產(chǎn)生的內(nèi)存占用也不會得到釋放，除非不再引用，才會逐步釋放。在正常的JavaScript執(zhí)行中，無法立即回收的內(nèi)存有閉包和全局變量引用這兩種情況，由于V8的內(nèi)存限制，要十分小心此類變量是否無限制地增加，因為它會導(dǎo)致老生代中的對象增多。

內(nèi)存指標

前面我們提到了process.memoryUsage()可以查看內(nèi)存使用的情況，除此之外，os模塊中的totalmem()和freemem()方法也可以查看內(nèi)存使用情況，這兩個方法用于查看操作系統(tǒng)的內(nèi)存使用情況，它們分別返回系統(tǒng)的總內(nèi)存和閑置內(nèi)存。

$ node
> process.memoryUsage()
{ rss: 13852672,
heapTotal: 6131200,
heapUsed: 2757120 }

其中rss是resident set size的簡寫，即進程的常駐內(nèi)存部分，進程的內(nèi)存總共有幾部分，一部分是rss，其余部分在交換區(qū)（swap）或者文件系統(tǒng)（filesystem）中，這3個值的單位都是字節(jié)。

var showMem = function () {
  var mem = process.memoryUsage();
  var format = function (bytes) {
    return (bytes / 1024 / 1024).toFixed(2) + ' MB';
  };
  console.log('Process: heapTotal ' + format(mem.heapTotal) +
  ' heapUsed ' + format(mem.heapUsed) + ' rss ' + format(mem.rss));
  console.log('-----------------------------------------------------------');
};

var useMem = function () {
  var size = 20 * 1024 * 1024;
  var arr = new Array(size);
  for (var i = 0; i < size; i++) {
    arr[i] = 0;
  }
  return arr;
};
var total = [];
for (var j = 0; j < 15; j++) {
  showMem();
  total.push(useMem());
}
showMem();

$ node outofmemory.js
Process: heapTotal 3.86 MB heapUsed 2.10 MB rss 11.16 MB
----------------------------------------------------------------
Process: heapTotal 357.88 MB heapUsed 353.95 MB rss 365.44 MB
----------------------------------------------------------------
Process: heapTotal 520.88 MB heapUsed 513.94 MB rss 526.30 MB
----------------------------------------------------------------
Process: heapTotal 679.91 MB heapUsed 673.86 MB rss 686.14 MB
----------------------------------------------------------------
Process: heapTotal 839.93 MB heapUsed 833.86 MB rss 846.16 MB
----------------------------------------------------------------
Process: heapTotal 999.94 MB heapUsed 993.86 MB rss 1006.93 MB
----------------------------------------------------------------
Process: heapTotal 1159.96 MB heapUsed 1153.86 MB rss 1166.95 MB
----------------------------------------------------------------
Process: heapTotal 1367.99 MB heapUsed 1361.86 MB rss 1375.00 MB
----------------------------------------------------------------
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory

可以看到，每次調(diào)用useMem到導(dǎo)致了3個值的增長，在接近1500MB的時候，無法繼續(xù)分配內(nèi)存，然后進程內(nèi)存溢出了，連循環(huán)體都無法執(zhí)行完成，僅執(zhí)行了7次。

通過process.memoryUsage()的結(jié)果可以看到，堆中的內(nèi)存用量總是小于進程的常駐內(nèi)存用量，這意味著Node中的內(nèi)存使用并非都是通過V8進行分配的，我們將那些不是通過V8分配的內(nèi)存稱為堆外內(nèi)存。

在這里我們修改useMem方法，將Array改為Buffer，將size變大，每一次構(gòu)造200MB的對象。

var useMem = function () {
  var size = 200 * 1024 * 1024;
  var buffer = new Buffer(size);
  for (var i = 0; i < size; i++) {
    buffer[i] = 0;
  }
  return buffer;
};

重新執(zhí)行該代碼：

$ node out_of_heap.js
Process: heapTotal 3.86 MB heapUsed 2.07 MB rss 11.12 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.94 MB rss 212.88 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.95 MB rss 412.89 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.95 MB rss 612.89 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.92 MB rss 812.89 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.92 MB rss 1012.89 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 1212.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 1412.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 1612.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 1812.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 2012.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 2212.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.84 MB rss 2412.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.85 MB rss 2612.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.85 MB rss 2812.91 MB
----------------------------------------------------------------
Process: heapTotal 5.85 MB heapUsed 1.85 MB rss 3012.91 MB
----------------------------------------------------------------

我們看到15次循環(huán)都完整執(zhí)行，并且三個內(nèi)存占用值與前一個示例完全不同，heapTotal和heapUsed變化極小，唯一變化的是rss的值，并且該值以及遠遠超過V8的限制值，這其中的原因是Buffer對象不同于其他對象，它不經(jīng)過V8的內(nèi)存分配機制，所以也不會有堆內(nèi)存的大小限制，這意味著使用堆外內(nèi)存可以突破內(nèi)存限制的問題。

為什么Bufer對象并非通過V8分配，這在于Node并不同于瀏覽器的應(yīng)用場景，在瀏覽器中，JavaScript直接處理字符串即可滿足絕大多數(shù)的業(yè)務(wù)需求，而Node則需要處理網(wǎng)絡(luò)流和文件I/O流，操作字符串遠遠不能滿足傳輸?shù)男阅苄枨?，因此Node的內(nèi)存構(gòu)成主要由通過V8進行分配的部分和Node自行分配的部分，受V8的垃圾回收限制的主要是V8的堆內(nèi)存。

內(nèi)存泄漏

內(nèi)存泄漏會造成堆積，垃圾回收過程中將會消耗更多時間進行對象掃描，應(yīng)用響應(yīng)緩慢，直到進程內(nèi)存溢出，應(yīng)用崩潰。盡管內(nèi)存泄漏的情況不盡相同，但其實質(zhì)只有一個，那就是應(yīng)當回收的對象出現(xiàn)意外而沒有被回收，變成了常駐的老生代中的對象。通常造成內(nèi)存泄漏的原因有如下幾個：緩存、隊列消費不及時、作用域未釋放。

慎將內(nèi)存當做緩存

JavaScript開發(fā)者通常喜歡用對象的鍵值對來緩存東西，但這與嚴格意義上的緩存又有著區(qū)別，嚴格意義的緩存有著完善的過期策略，而普通的鍵值對并沒有。

_.memoize = function(func, hasher) {
  var memo = {};
  hasher || (hasher = _.identity);
  return function() {
    // 根據(jù)函數(shù)的參數(shù)形成不同的hash值，以此為鍵將結(jié)果緩存在memo上。
    var key = hasher.apply(this, arguments);
    return _.has(memo, key) ? memo[key] : (memo[key] = func.apply(this, arguments));
  };
};

它的原理是以參數(shù)作為鍵進行緩存，以內(nèi)存空間換CPU執(zhí)行時間，這里潛藏的陷阱即是每個被執(zhí)行的結(jié)果都會按參數(shù)緩存在memo對象上，不會被清楚。這在前端網(wǎng)頁這種短時應(yīng)用場景中不存在大問題，但是執(zhí)行量大和參數(shù)多樣性的情況，會造成內(nèi)存占用不釋放，如果需要，可以限制緩存對象的大小，加上過期策略以防止內(nèi)存無限制增長。

var LimitableMap = function (limit) {
  this.limit = limit || 10;
  this.map = {};
  this.keys = [];
};
var hasOwnProperty = Object.prototype.hasOwnProperty;

LimitableMap.prototype.set = function (key, value) {
  var map = this.map;
  var keys = this.keys;
  if (!hasOwnProperty.call(map, key)) {
    // 如果沒有緩存，判斷對象擁有的屬性數(shù)量是否超過限制
    if (keys.length === this.limit) {
      // 超過限制，淘汰第一次緩存的數(shù)據(jù)，再緩存
      var firstKey = keys.shift();
      delete map[firstKey];
    }
    // 未超過限制，緩存起來
    keys.push(key);
  }
  // 如果有緩存，直接替換
  map[key] = value;
};

LimitableMap.prototype.get = function (key) {
  return this.map[key];
};
module.exports = LimitableMap;

另一個案例在于模塊機制，為了加速模塊的引入，所有的模塊都會通過編譯執(zhí)行，然后被緩存起來，由于通過exports導(dǎo)出的函數(shù)可以訪問文件模塊中的私有變量，這樣每個文件模塊在編譯執(zhí)行后形成的作用域因為模塊緩存的原因不會被釋放。

由于模塊的緩存機制，模塊是常駐老生代的，所有在設(shè)計模塊時，要十分小心內(nèi)存泄漏的情況。也可以添加清空隊列的相應(yīng)接口，以供調(diào)用者釋放內(nèi)存。

緩存的解決方案

直接將內(nèi)存作為緩存的方案要十分慎重，除了限制緩存的大小，另外要考慮的事情是，進程之間無法共享內(nèi)存，如果在進程內(nèi)使用緩存，這些緩存不可避免地有重復(fù)，對物理內(nèi)存的使用是一種浪費，如何使用大量緩存，目前比較好的解決方案是采用進程外的緩存，進程自身不存儲狀態(tài)，外部緩存軟件有著良好的緩存過期淘汰策略以及自有的內(nèi)存管理，不影響Node進程的性能，它的好處多多，在Node中主要可以解決以下兩個問題。

1、將緩存轉(zhuǎn)移到外部，減少常駐內(nèi)存的對象的數(shù)量，讓垃圾回收更高效。

2、進程之間可以共享緩存。

{{% notice info %}}
其中較好的緩存有Redis 和 Memcached
{{% /notice %}}

關(guān)注隊列狀態(tài)

隊列在消費者-生產(chǎn)者模型中經(jīng)常充當中間產(chǎn)物，這是一個容易忽略的情況，因為大多數(shù)應(yīng)用場景下，消費的速度遠遠大于生產(chǎn)的速度，內(nèi)存泄漏不易產(chǎn)生，但是一旦消費速度低于生產(chǎn)速度，將會形成堆積。

比如：有的應(yīng)用會收集日志，如果欠缺考慮，也許會采用數(shù)據(jù)庫來記錄日志，日志通常是海量的，而數(shù)據(jù)庫的寫入效率遠遠低于文件直接寫入，于是會造成數(shù)據(jù)庫寫入操作的堆積，而JavaScript相關(guān)的作用域也不會得到釋放，內(nèi)存占用不會回落，從而出現(xiàn)內(nèi)存泄漏。

表層的解決方案，是換用消費速度更高的技術(shù)，換用文件寫入日志的方式，但是需要注意的是，如果生產(chǎn)速度因為某些原因突然激增，后者消費速度因為突然的系統(tǒng)故障降低，內(nèi)存泄漏還是可能出現(xiàn)的。

深度的解決方案應(yīng)該是控制隊列的長度，一旦堆積，應(yīng)當通過監(jiān)控系統(tǒng)產(chǎn)生報警并通知相關(guān)人員，另一個解決方案是任意異步調(diào)用都應(yīng)該包含超時機制，一旦在限定時間內(nèi)未完成響應(yīng)，通過回調(diào)函數(shù)傳遞異常，完成回落，使得任意異步調(diào)用都具備可控的響應(yīng)時間，給消費速度一個下限值。

內(nèi)存泄漏排查

現(xiàn)在有許多工具用于定位Node的內(nèi)存泄漏，下面介紹其中的2種，node-heapdump 和 node-memwatch

node-heapdump

安裝：npm install heapdump

使用：

var heapdump = require('heapdump'); // 引入
var http = require('http');
// 寫一份內(nèi)存泄漏的代碼
var leakArray = [];
var leak = function () {
  leakArray.push(new Array(2 * 1024 * 1024));
};
http.createServer(function (req, res) {
  leak();
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337);

上述代碼在使用node跑起來之后，每次請求localhost:1337都會使得leakArray數(shù)組中的元素增加，而得不到回收，我們在多次訪問之后，leakArray的每一項都是較大的數(shù)組，這時候輸入命令可以使用headdump抓拍一份堆內(nèi)存的快照。

1、使用 lsof -i:1337 查看1337端口上的進程的pid
2、輸入以下命令抓取
kill -USR2 <pid>  // pid 進程號

這份抓取的快照會在文件目錄下以heapdump-<sec>.<usec>.heapsnapshot的格式存放，這是一份較大的JSON文件，需要通過Chrome的開發(fā)者工具打開查看，開發(fā)者工具 - Memory - Profiles - 點擊右下角的load打開剛才的快照文件，就可以查看堆內(nèi)存中的詳細信息，可以查看內(nèi)存分布，可以找出泄漏的數(shù)據(jù)，然后根據(jù)這些信息找到泄漏的代碼。

heapdump.png

node-memwatch

安裝： npm install memwatch

使用：

var memwatch = require('memwatch');
var http = require('http');

memwatch.on('leak', function (info) {
  console.log('leak:');
  console.log(info);
});
memwatch.on('stats', function (stats) {
  console.log('stats:')
  console.log(stats);
});

var leakArray = [];
var leak = function () {
  leakArray.push("leak" + Math.random());
};

http.createServer(function (req, res) {
  leak();
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337);
console.log('Server running at http://127.0.0.1:1337/');

在進程使用node-memwatch之后，每次進行全堆垃圾收集時，將會觸發(fā)一次stats事件，這個事件將會傳遞內(nèi)存的統(tǒng)計信息，在對上述代碼創(chuàng)建的服務(wù)進程進行訪問時，某次stats事件打印的數(shù)據(jù)如下所示。

stats:
{ 
  num_full_gc: 4, // 第幾次全堆垃圾回收
  num_inc_gc: 23, // 第幾次增量垃圾回收
  heap_compactions: 4, // 第幾次對老生代進行整理
  usage_trend: 0, // 使用趨勢
  estimated_base: 7152944, // 預(yù)估基數(shù)
  current_base: 7152944, // 當前基數(shù)
  min: 6720776, // 最小
  max: 7152944  // 最大
}

如果經(jīng)過連續(xù)5次垃圾回收后，內(nèi)存仍然沒有得到釋放，這意味著有內(nèi)存泄漏的產(chǎn)生，這時候node-memwatch會觸發(fā)一個leak事件，某次leak事件得到的數(shù)據(jù)如下：

leak:
{ 
  start: Mon Oct 07 2013 13:46:27 GMT+0800 (CST),
  end: Mon Oct 07 2013 13:54:40 GMT+0800 (CST),
  growth: 6222576,
  reason: 'heap growth over 5 consecutive GCs (8m 13s) - 43.33 mb/hr' 
}

這個數(shù)據(jù)能顯示5次垃圾回收的過程中內(nèi)存增長了多少，而具體問題產(chǎn)生在何處還需要從V8堆內(nèi)存上定位，node-memwatch提供了抓取快照和比較快照的功能，它能夠比較堆上對象的名稱和分配數(shù)量，從而找到導(dǎo)致內(nèi)存泄漏的元兇。

var memwatch = require('memwatch');
var leakArray = [];

var leak = function () {
  leakArray.push("leak" + Math.random());
};
// 抓取第一次
var hd = new memwatch.HeapDiff();
for (var i = 0; i < 10000; i++) {
leak();
}
// 抓取第二次并進行比較得出diff
var diff = hd.end();
console.log(JSON.stringify(diff, null, 2));

運行以上代碼，得到j(luò)son字符串如下。

{
  "before": {
    "nodes": 11719,
    "time": "2013-10-07T06:32:07.000Z",
    "size_bytes": 1493304,
    "size": "1.42 mb"
  },
  "after": {
    "nodes": 31618,
    "time": "2013-10-07T06:32:07.000Z",
    "size_bytes": 2684864,
    "size": "2.56 mb"
  },
  "change": {
    "size_bytes": 1191560,
    "size": "1.14 mb",
    "freed_nodes": 129,
    "allocated_nodes": 20028,
    "details": [
      {
        "what": "Array",
        "size_bytes": 323720,
        "size": "316.13 kb",
        "+": 15,
        "-": 65
      },
      {
        "what": "Code",
        "size_bytes": -10944,
        "size": "-10.69 kb",
        "+": 8,
        "-": 28
      },
      {
        "what": "String",
        "size_bytes": 879424,
        "size": "858.81 kb",
        "+": 20001,
        "-": 1
      }
    ]
  }
}

其中change節(jié)點下的freed_nodes和allocated_nodes，記錄了釋放的節(jié)點數(shù)量和分配的節(jié)點數(shù)量，由于內(nèi)存泄漏，分配的節(jié)點數(shù)量遠遠多余釋放的節(jié)點數(shù)量。

在detail數(shù)組可以看出每種類型的分配和釋放數(shù)量，+ 和 - 號分別表示分配和釋放的對象數(shù)量，其中可以看出有大量的字符串沒有被回收。

大內(nèi)存應(yīng)用

由于Node的內(nèi)存限制，操作大文件也需要小心，好在Node提供了stream模塊用于處理大文件。

stream是Node原生模塊，繼承自EventEmitter，具備基本的自定義事件功能，同時抽象出標準的事件和方法， 在Node中大多數(shù)模塊都有stream的應(yīng)用，比如fs的createReadStream()和createWriteStream()方法可以分別用于創(chuàng)建文件的可讀流和可寫流，process模塊中stdin和stdout分別是可讀流和可寫流的示例。

由于V8的內(nèi)存限制，我們無法通過fs.readFile()和fs.writeFile()直接進行大文件的操作，而改用fs.createReadStream()和fs.createWriteStream()方法通過流的方式實現(xiàn)對大文件的操作。

var reader = fs.createReadStream('in.txt');
var writer = fs.createWriteStream('out.txt');

reader.on('data', function (chunk) {
  writer.write(chunk);
});
reader.on('end', function () {
  writer.end();
});

// 或者簡寫為

var reader = fs.createReadStream('in.txt');
var writer = fs.createWriteStream('out.txt');
reader.pipe(writer);

可讀流提供了管道方法pipe()，封裝了data事件和寫入操作，通過流的方式，上述代碼不會受到V8內(nèi)存限制的影響，有效的提高了程序的健壯性。

如果不需要進行字符串層面的操作，則不需要借助V8來處理，可以嘗試進行純粹的Buffer操作，這不會受到V8堆內(nèi)存的限制。但是需要注意的是，物理內(nèi)存仍然有限制。