Node.js HTTP 模塊的內存泄露問題
很久沒有逛社區了，晚上回來看了一下最近的情況，突然看到一個內存泄露問題，作為一個 APM 開發者，自然想分析其中的原因。
問題
下面介紹一下具體的問題。看一下 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 下執行上面代碼（node --expose-gc demo.js）輸出如下。
2681120
11409488
19632792
28038016
36438104可以看到內存不斷在增長。下面來分析這個問題。
分析
const http = require('http');
const v8 = require('v8');
for (i = 0; i < 1000; i++) {
http.createServer((req, res) => {});
}
v8.writeHeapSnapshot('memory-leaky.heapsnapshot');采集的快照如下。
圖片
可以看到，Server 對象沒有被釋放。看一下是誰引用了它。
圖片
是定時器引用了 Server 對象，我們看一下定時器對象又是被誰引用了。
圖片
有一個關鍵的變量 connectionsCheckingInterval，到 Node.js 源碼里看一下，最終發現是 Server 初始化時創建的。
function Server(options, requestListener) {
setupConnectionsTracking(this);
}
function setupConnectionsTracking(server) {
server[kConnectionsCheckingInterval] = setInterval(checkConnections.bind(server), server.connectionsCheckingInterval).unref();
}可以看到 checkConnections.bind 返回的匿名函數持有了 Server，而匿名函數又被 setInterval 持有了，所以導致 Server 對象無法釋放。
修復
那么如何修復這個問題呢？修復這個問題，首先需要了解 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 是追蹤連接超時，回到我們的測試例子中可以發現，我們并沒有執行 listen，也就是說，Server 對象并不會處理連接，那么也就沒有連接需要追蹤，所以修復方式就是把調用 setupConnectionsTracking 的時機延遲到 listen 成功時，修復代碼大致如下。
function Server(options, requestListener) {
this.on('listening', () => {
setupConnectionsTracking(this);
});
}修改源碼重新編譯后測試結果如下。
3653552
4002680
3753400
3762976
3773088可以看到內存已經不會增長了，采集快照也可以看到不會再存在大量 Server 對象。
總結
這個例子雖然看起來有點不常見，用法也很怪異，但是從側面說明了雖然 JS 自帶 GC，但是因為邏輯 / 引用關系復雜，還是很容易出現內存泄露問題，所以寫代碼時還是需要注意，具體的 issue 可以參考 https://github.com/nodejs/node/issues/48604。
