在后端渲染（SSR）微服务架构中，有一个专门负责生成市级心理评估报告矢量雷达图的 Node.js 服务。该服务主要依赖 Puppeteer 和 ECharts 进行图表的无头浏览器渲染。
该服务上线初期运行平稳，但几天后运维监控显示出一个异常趋势：Node.js 进程的内存占用呈持续上升态势，从初始的 150MB 逐渐攀升至 1.5GB。当内存达到 V8 引擎的物理上限时，进程因 OOM（Out Of Memory）而崩溃。尽管 Kubernetes 集群会自动重启该服务，但随着时间推移，内存耗尽的现象依然会反复出现。
这类问题通常指向了 Node.js 开发中常见的内存泄漏。本文将回顾如何利用 V8 的 HeapSnapshot 工具，排查并修复由于事件监听器未正确释放而导致的闭包内存泄漏。
在排查内存泄漏时，保留进程崩溃前的内存快照是关键。在 Node.js 内存占用显著偏高但尚未崩溃时，可以通过原生的 v8 模块生成 HeapSnapshot 文件：
“`javascript
const v8 = require(‘v8’);
// 生成内存快照文件以便后续分析
v8.writeHeapSnapshot(‘./memory-crash-scene.heapsnapshot’);
“`
将该快照文件导入 Chrome DevTools 的 Memory 面板后，我们可以按 Retained Size（保留大小，即对象本身及其引用的所有对象占用的内存总和）对内存对象进行降序排列。
在排查过程中，我们发现占用内存最多的是一个包含大量闭包（Closure）的数组。顺着引用的保留树（Retainers）逐层查看，最终定位到这些闭包都被一个名为 systemMonitor 的 EventEmitter 实例所引用。
结合快照中的上下文，我们审视了 SSR 图表服务中的业务代码。在处理并发请求时，存在如下的事件监听逻辑：
“`javascript
// 全局单例的事件派发器
const systemMonitor = new EventEmitter();
function renderPsyChart(studentData) {
// 每次请求到达时，都注册了一个新的事件监听器
systemMonitor.on(‘resourceReady’, () => {
// 闭包内部引用了请求上下文中的 studentData 对象
processData(studentData);
});
// …执行后续的图表渲染逻辑…
}
“`
问题在于，systemMonitor 是一个生命周期伴随整个进程的全局对象。每次调用 renderPsyChart 处理请求时，都会向其注册一个新的回调函数。这个回调函数作为一个闭包，内部引用了体积较大的 studentData 对象。
当单次请求处理结束后，按理说相关的上下文数据应当被垃圾回收器（GC）清理。但由于全局的 systemMonitor 依然持有对这些回调函数的引用，导致作用域内的 studentData 也无法被回收。随着请求量的累积，这些未被释放的内存块不断增加，最终导致了 V8 引擎内存溢出。
针对这类问题，橙星云技术团队在开发规范中明确要求：在局部作用域内注册的事件监听器，必须在生命周期结束时手动解除绑定。
修复后的代码如下：
“`javascript
function renderPsyChart(studentData) {
const handler = () => {
processData(studentData);
};
systemMonitor.on(‘resourceReady’, handler);
// 请求处理完毕后，确保移除对应的监听器
renderFinalChart().finally(() => {
systemMonitor.off(‘resourceReady’, handler);
});
}
“`
经过这一修改，回调函数及其闭包引用的数据在请求结束后能够被正常释放。重新部署后，该微服务的内存占用保持在安全的稳定水平，内存泄漏问题得到解决。
在 Node.js 长期运行的应用中，全局变量或长生命周期对象上的事件监听器是引发内存泄漏的常见原因。通过在关键节点生成 HeapSnapshot 并借助工具分析保留树，开发者可以准确定位未释放的引用。保持严谨的事件监听和解绑习惯，是维护 Node.js 内存健康状态的必要工程实践。