App下載

關(guān)于Node.js內(nèi)存泄漏問題的分析

猿友 2020-08-24 15:30:49 瀏覽數(shù) (3271)
反饋

本文將會先給大家介紹一些理論知識，隨后再附上一個(gè)關(guān)于內(nèi)存泄漏的案例，有興趣的同學(xué)可以繼續(xù)往下看。

Node.js 使用 V8 引擎，它的特點(diǎn)是會自動(dòng)進(jìn)行垃圾回收（Garbage Collection，GC），所以我們在寫代碼的時(shí)候就不需要像C/C++ 一樣去手動(dòng)分配、釋放內(nèi)存空間，方便不少，不過仍然需要注意內(nèi)存的使用，避免造成內(nèi)存泄漏（Memory Leak）。

由緩存問題引發(fā)的Node.js內(nèi)存泄漏分析

從上圖中，可以看到 Node.js 的常駐內(nèi)存（Resident Set）分為堆和棧兩個(gè)部分，具體為：

  • 堆

    • 指針空間（Old pointer space）：存儲的對象含有指向其它對象的指針。
    • 數(shù)據(jù)空間（Old data space）：存儲的對象僅含有數(shù)據(jù)（不含指向其它對象的指針），例如從新生代移動(dòng)過來的字符串等。
    • 新生代（New Space/Young Generation）：用來臨時(shí)存儲新對象，空間被等分為兩份，整體較小，采用 Scavenge（Minor GC） 算法進(jìn)行垃圾回收。
    • 老生代（Old Space/Old Generation）：用來存儲存活時(shí)間超過兩個(gè) Minor GC 時(shí)間的對象，采用 標(biāo)記清除 & 整理（Mark-Sweep & Mark-Compact，Major GC） 算法進(jìn)行垃圾回收，內(nèi)部可再劃分為兩個(gè)空間：
    • 代碼空間（Code Space）：用于存放代碼段，是唯一的可執(zhí)行內(nèi)存（不過過大的代碼段也有可能存放在大對象空間）。
    • 大對象空間（Large Object Space）：用于存放超過其它空間對象限制（Page::kMaxRegularHeapObjectSize）的大對象（可以參考這個(gè) V8 Commit），存放在此的對象不會在垃圾回收的時(shí)候被移動(dòng)。
    • ...

  • 棧：用于存放原始的數(shù)據(jù)類型，函數(shù)調(diào)用時(shí)的入棧出棧也記錄于此。

棧的空間由操作系統(tǒng)負(fù)責(zé)管理，開發(fā)者無需過于關(guān)心；堆的空間由 V8 引擎進(jìn)行管理，可能由于代碼問題出現(xiàn)內(nèi)存泄漏，或者長時(shí)間運(yùn)行后，垃圾回收導(dǎo)致程序運(yùn)行速度變慢。

（推薦教程：Node入門）

我們可以通過下面代碼簡單的觀察 Node.js 內(nèi)存使用情況：

const format = function (bytes) {
  return `${(bytes / 1024 / 1024).toFixed(2)} MB`;
};


const memoryUsage = process.memoryUsage();


console.log(JSON.stringify({
    rss: format(memoryUsage.rss), // 常駐內(nèi)存
    heapTotal: format(memoryUsage.heapTotal), // 總的堆空間
    heapUsed: format(memoryUsage.heapUsed), // 已使用的堆空間
    external: format(memoryUsage.external), // C++ 對象相關(guān)的空間
}, null, 2));

external 是 C++ 對象相關(guān)的空間，例如通過 new ArrayBuffer(100000); 申請一塊 Buffer 內(nèi)存的時(shí)候，可以明顯看到 external 空間的增加。

可以通過下列參數(shù)調(diào)整相關(guān)空間的默認(rèn)大小，單位為 MB：

  • --stack_size 調(diào)整?？臻g
  • --min_semi_space_size 調(diào)整新生代半空間的初始值
  • --max_semi_space_size 調(diào)整新生代半空間的最大值
  • --max-new-space-size 調(diào)整新生代空間的最大值
  • --initial_old_space_size 調(diào)整老生代空間的初始值
  • --max-old-space-size 調(diào)整老生代空間的最大值

其中比較常用的是 --max_new_space_size 和 --max-old-space-size。

新生代的 Scavenge 回收算法、老生代的 Mark-Sweep & Mark-Compact 算法相關(guān)的文章已經(jīng)很多，這里就不贅述了。

內(nèi)存泄漏

由于不當(dāng)?shù)拇a，有時(shí)候難免會發(fā)生內(nèi)存泄漏，常見的有四個(gè)場景：

  1. 全局變量
  2. 閉包引用
  3. 事件綁定
  4. 緩存爆炸

接下來分別舉個(gè)例子講一講。

全局變量

沒有使用 var/let/const 聲明的變量會直接綁定在 Global對象上（Node.js 中）或者 Windows 對象上（瀏覽器中），哪怕不再使用，仍不會被自動(dòng)回收：

function test() {
  x = new Array(100000);
}


test();
console.log(x);

這段代碼的輸出為 [ <100000 empty items> ]，可以看到 test 函數(shù)運(yùn)行完后，數(shù)組 x 仍未被釋放。

閉包引用

閉包引發(fā)的內(nèi)存泄漏往往非常隱蔽，例如下面這段代碼你能看出來是哪兒里有問題嗎？

let theThing = null;
let replaceThing = function() {
  const newThing = theThing;
  const unused = function() {
    if (newThing) console.log("hi");
  };
  // 不斷修改引用
  theThing = {
    longStr: new Array(1e8).join("*"),
    someMethod: function() {
      console.log("a");
    },
  };


  // 每次輸出的值會越來越大
  console.log(process.memoryUsage().heapUsed);
};


setInterval(replaceThing, 100);

運(yùn)行這段代碼可以看到輸出的已使用堆內(nèi)存越來越大，而其中的關(guān)鍵就是因?yàn)?在目前的 V8 實(shí)現(xiàn)當(dāng)中，閉包對象是當(dāng)前作用域中的所有內(nèi)部函數(shù)作用域共享的，也就是說 theThing.someMethod 和 unUsed 共享同一個(gè)閉包的 context，導(dǎo)致 theThing.someMethod 隱式的持有了對之前的 newThing 的引用，所以會形成 theThing -> someMethod -> newThing -> 上一次 theThing ->...的循環(huán)引用，從而導(dǎo)致每一次執(zhí)行 replaceThing 這個(gè)函數(shù)的時(shí)候，都會執(zhí)行一次 longStr: new Array(1e8).join("*")，而且其不會被自動(dòng)回收，導(dǎo)致占用的內(nèi)存越來越大，最終內(nèi)存泄漏。

對于上面這個(gè)問題有一個(gè)很巧妙的解決方法：通過引入新的塊級作用域，將 newThing 的聲明、使用與外部隔離開，從而打破共享，阻止循環(huán)引用。

let theThing = null;
let replaceThing = function() {
  {
    const newThing = theThing;
    const unused = function() {
      if (newThing) console.log("hi");
    };
  }
  // 不斷修改引用
  theThing = {
    longStr: new Array(1e8).join("*"),
    someMethod: function() {
      console.log("a");
    },
  };


  console.log(process.memoryUsage().heapUsed);
};


setInterval(replaceThing, 100);

這里通過 { ... }形成了單獨(dú)的塊級作用域，而且在外部沒有引用，從而 newThing 在 GC 的時(shí)候會被自動(dòng)回收，例如在我的電腦運(yùn)行這段代碼輸出如下：

2097128
2450104
2454240
...
2661080
2665200
2086736 // 此時(shí)進(jìn)行垃圾回收釋放了內(nèi)存
2093240

事件綁定

事件綁定導(dǎo)致的內(nèi)存泄漏在瀏覽器中非常常見，一般是由于事件響應(yīng)函數(shù)未及時(shí)移除，導(dǎo)致重復(fù)綁定或者 DOM 元素已移除后未處理事件響應(yīng)函數(shù)造成的，例如下面這段 React 代碼：

class Test extends React.Component {
  componentDidMount() {
    window.addEventListener('resize', function() {
      // 相關(guān)操作
    });
  }


  render() {
    return <div>test component</div>;
  }
}

<Test /> 組件在掛載的時(shí)候監(jiān)聽了 resize 事件，但是在組件移除的時(shí)候沒有處理相應(yīng)函數(shù)，假如 <Test /> 的掛載和移除非常頻繁，那么就會在 window 上綁定很多無用的事件監(jiān)聽函數(shù)，最終導(dǎo)致內(nèi)存泄漏?？梢酝ㄟ^如下的方式避免這個(gè)問題：

class Test extends React.Component {
  componentDidMount() {
    window.addEventListener('resize', this.handleResize);
  }


  handleResize() { ... }


  componentWillUnmount() {
    window.removeEventListener('resize', this.handleResize);
  }


  render() {
    return <div>test component</div>;
  }
}

（推薦教程：Node.js教程）

緩存爆炸

通過 Object/Map 的內(nèi)存緩存可以極大地提升程序性能，但是很有可能未控制好緩存的大小和過期時(shí)間，導(dǎo)致失效的數(shù)據(jù)仍緩存在內(nèi)存中，導(dǎo)致內(nèi)存泄漏：

const cache = {};


function setCache() {
  cache[Date.now()] = new Array(1000);
}


setInterval(setCache, 100);

上面這段代碼中，會不斷的設(shè)置緩存，但是沒有釋放緩存的代碼，導(dǎo)致內(nèi)存最終被撐爆。

如果的確需要進(jìn)行內(nèi)存緩存的話，強(qiáng)烈建議使用 lru-cache這個(gè) npm 包，可以設(shè)置緩存有效期和最大的緩存空間，通過 LRU 淘汰算法來避免緩存爆炸。

內(nèi)存泄漏定位實(shí)操

當(dāng)出現(xiàn)內(nèi)存泄漏的時(shí)候，定位起來往往十分麻煩，主要有兩個(gè)原因：

  1. 程序開始運(yùn)行的時(shí)候，問題不會立即暴露，需要持續(xù)的運(yùn)行一段時(shí)間，甚至一兩天，才會復(fù)現(xiàn)問題。
  2. 出錯(cuò)的提示信息非常模糊，往往只能看到 heap out of memory 錯(cuò)誤信息。

在這種情況下，可以借助兩個(gè)工具來定問題：Chrome DevTools 和 heapdump。heapdump的作用就如同它的名字所說 - 將內(nèi)存中堆的狀態(tài)信息生成快照（snapshot）導(dǎo)出，然后我們將其導(dǎo)入到 Chrome DevTools 中看到具體的詳情，例如堆中有哪些對象、占據(jù)多少空間等等。

接下來通過上文中閉包引用里內(nèi)存泄漏的例子，來實(shí)際操作一把。首先 npm install heapdump 安裝后，修改代碼為下面的樣子：

// 一段存在內(nèi)存泄漏問題的示例代碼
const heapdump = require('heapdump');


heapdump.writeSnapshot('init.heapsnapshot'); // 記錄初始內(nèi)存的堆快照


let i = 0; // 記錄調(diào)用次數(shù)
let theThing = null;
let replaceThing = function() {
  const newThing = theThing;
  let unused = function() {
    if (newThing) console.log("hi");
  };


  // 不斷修改引用
  theThing = {
    longStr: new Array(1e8).join("*"),
    someMethod: function() {
      console.log("a");
    },
  };


  if (++i >= 1000) {
    heapdump.writeSnapshot('leak.heapsnapshot'); // 記錄運(yùn)行一段時(shí)間后內(nèi)存的堆快照
    process.exit(0);
  }
};


setInterval(replaceThing, 100);

在第 3 行和第 22 行，分別導(dǎo)出了初始狀態(tài)的快照和循環(huán)了 1000 次后的快照，保存為 init.heapsnapshot 與 leak.heapsnapshot。

然后打開 Chrome 瀏覽器，按下 F12 調(diào)出DevTools 面板，點(diǎn)擊 Memory 的 Tab，最后通過 Load 按鈕將剛剛的兩個(gè)快照依次導(dǎo)入：

關(guān)于Node.js內(nèi)存泄漏問題的分析

導(dǎo)入后，在左側(cè)可以看到堆內(nèi)存有明顯的上漲，從 1.7 MB 上漲到了 3.1 MB，幾乎翻了一倍：

關(guān)于Node.js內(nèi)存泄漏問題的分析

接下來就是最關(guān)鍵的步驟了，點(diǎn)擊 leak 快照，然后將其與 init 快照進(jìn)行對比：

關(guān)于Node.js內(nèi)存泄漏問題的分析

右側(cè)紅框圈出來了兩列：

  • Delta：表示變化的數(shù)量
  • Size Delta：表述變化的空間大小

可以看到增長最大的前兩項(xiàng)是 拼接的字符串（concatenated string ） 和 閉包（closure），那么我們點(diǎn)開來看看具體有哪些：

關(guān)于Node.js內(nèi)存泄漏問題的分析

關(guān)于Node.js內(nèi)存泄漏問題的分析

從這兩個(gè)圖中，可以很直觀的看出來主要是 theThing.someMethod 這個(gè)函數(shù)的閉包上下文和 theThing.longStr 這個(gè)很長的拼接字符串造成的內(nèi)存泄漏，到這里問題就基本定位清楚了，我們還可以點(diǎn)擊下方的 Object 模塊來更清楚的看一下調(diào)用鏈的關(guān)系：

關(guān)于Node.js內(nèi)存泄漏問題的分析

圖中很明顯的看出來，內(nèi)存泄漏原因就是因?yàn)?newTHing <- 閉包上下文 <- someMethod<- 上一次 newThing 這樣的鏈?zhǔn)揭蕾囮P(guān)系導(dǎo)致內(nèi)存的快速增長。圖中第二列的 distance 表示的是該變量距離根節(jié)點(diǎn)的距離，因而最上級的 newThing 是最遠(yuǎn)的，表示的是下級引用上級的關(guān)系。

（推薦微課：Node.js微課）

文章來源：www.toutiao.com/a6863362442957849102/

以上就是W3Cschool編程獅關(guān)于關(guān)于Node.js內(nèi)存泄漏問題的分析的相關(guān)介紹了，希望對大家有所幫助。

匯編語言

0 人點(diǎn)贊