自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Node.js HTTP 模塊的內(nèi)存泄露問題

開發(fā) 前端
setupConnectionsTracking 是追蹤連接超時(shí),回到我們的測試?yán)又锌梢园l(fā)現(xiàn),我們并沒有執(zhí)行 listen,也就是說,Server 對象并不會(huì)處理連接,那么也就沒有連接需要追蹤,所以修復(fù)方式就是把調(diào)用 setupConnectionsTracking 的時(shí)機(jī)延遲到 listen 成功時(shí),修復(fù)代碼大致如下。

很久沒有逛社區(qū)了,晚上回來看了一下最近的情況,突然看到一個(gè)內(nèi)存泄露問題,作為一個(gè) APM 開發(fā)者,自然想分析其中的原因。

問題

下面介紹一下具體的問題??匆幌?demo。

const http = require('http')

async function main () {
  let i = 0
  while (true) {
    if (i % 100 === 0) {
      global.gc()
    }

    if (i % 10000 === 0) {
      console.log(process.memoryUsage().heapUsed)
    }

    http.createServer((req, res) => {})
    i++
  }
}

main()

Node.js v20.3.1 下執(zhí)行上面代碼(node --expose-gc demo.js)輸出如下。

2681120
11409488
19632792
28038016
36438104

可以看到內(nèi)存不斷在增長。下面來分析這個(gè)問題。

分析

const http = require('http');
const v8 = require('v8');

for (i = 0; i < 1000; i++) {
    http.createServer((req, res) => {});
}
v8.writeHeapSnapshot('memory-leaky.heapsnapshot');

采集的快照如下。

圖片圖片

可以看到,Server 對象沒有被釋放??匆幌率钦l引用了它。

圖片圖片

是定時(shí)器引用了 Server 對象,我們看一下定時(shí)器對象又是被誰引用了。

圖片圖片

有一個(gè)關(guān)鍵的變量 connectionsCheckingInterval,到 Node.js 源碼里看一下,最終發(fā)現(xiàn)是 Server 初始化時(shí)創(chuàng)建的。

function Server(options, requestListener) {
  setupConnectionsTracking(this);
}

function setupConnectionsTracking(server) {
  server[kConnectionsCheckingInterval] = setInterval(checkConnections.bind(server), server.connectionsCheckingInterval).unref();
}

可以看到 checkConnections.bind 返回的匿名函數(shù)持有了 Server,而匿名函數(shù)又被 setInterval 持有了,所以導(dǎo)致 Server 對象無法釋放。

修復(fù)

那么如何修復(fù)這個(gè)問題呢?修復(fù)這個(gè)問題,首先需要了解 setupConnectionsTracking 是做什么的,邏輯如下。

function checkConnections() {
  if (this.headersTimeout === 0 && this.requestTimeout === 0) {
    return;
  }

  const expired = this[kConnections].expired(this.headersTimeout, this.requestTimeout);

  for (let i = 0; i < expired.length; i++) {
    const socket = expired[i].socket;

    if (socket) {
      onRequestTimeout(socket);
    }
  }
}

可以看到,setupConnectionsTracking 是追蹤連接超時(shí),回到我們的測試?yán)又锌梢园l(fā)現(xiàn),我們并沒有執(zhí)行 listen,也就是說,Server 對象并不會(huì)處理連接,那么也就沒有連接需要追蹤,所以修復(fù)方式就是把調(diào)用 setupConnectionsTracking 的時(shí)機(jī)延遲到 listen 成功時(shí),修復(fù)代碼大致如下。

function Server(options, requestListener) {
  this.on('listening', () => {
    setupConnectionsTracking(this);
  });
}

修改源碼重新編譯后測試結(jié)果如下。

3653552
4002680
3753400
3762976
3773088

可以看到內(nèi)存已經(jīng)不會(huì)增長了,采集快照也可以看到不會(huì)再存在大量 Server 對象。

總結(jié)

這個(gè)例子雖然看起來有點(diǎn)不常見,用法也很怪異,但是從側(cè)面說明了雖然 JS 自帶 GC,但是因?yàn)檫壿?/ 引用關(guān)系復(fù)雜,還是很容易出現(xiàn)內(nèi)存泄露問題,所以寫代碼時(shí)還是需要注意,具體的 issue 可以參考 https://github.com/nodejs/node/issues/48604。

責(zé)任編輯:武曉燕 來源: 編程雜技
相關(guān)推薦

2025-01-08 08:47:44

Node.js內(nèi)存泄露定時(shí)器

2021-09-26 05:06:04

Node.js模塊機(jī)制

2020-04-15 15:48:03

Node.jsstream前端

2019-12-17 11:40:44

Node.js模塊前端

2017-03-19 16:40:28

漏洞Node.js內(nèi)存泄漏

2017-03-20 13:43:51

Node.js內(nèi)存泄漏

2022-01-02 06:55:08

Node.js ObjectWrapAddon

2020-01-03 16:04:10

Node.js內(nèi)存泄漏

2021-10-03 15:02:50

HTTPNodejs

2014-09-12 10:35:09

Node.jsHTTP 206

2022-06-23 06:34:56

Node.js子線程

2011-12-09 11:16:48

Node.js

2013-11-01 09:34:56

Node.js技術(shù)

2015-03-10 10:59:18

Node.js開發(fā)指南基礎(chǔ)介紹

2011-09-08 14:07:28

Node.js

2023-06-20 19:35:00

Node.js工具

2022-03-02 09:01:30

Node.js v1HTTPNode.j

2017-04-24 08:31:26

Node.jsExpress.jsHTTP

2020-08-31 15:00:17

Node.jsrequire前端

2021-01-26 08:07:44

Node.js模塊 Async
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)