NodeJS API运行Jest单元/集成测试时内存泄漏问题排查求助

问题背景 #

• 自研NodeJS API执行Jest单元测试、集成测试过程中出现疑似内存泄漏异常
• 已尝试将Jest从26.3.2版本升级至27.5.1版本，问题无明显改善
• 采集4份Chrome堆内存快照观测到内存涨幅异常，暂未定位根因，已确认三类异常占用对象：
  1. String对象：存在大量类库序列化版本的重复字符串条目，来源暂不明确
  2. Object对象：异常实例疑似来自依赖countries-list（该库用于获取国家列表、查询国家ISO编码）
  3. JSBufferData对象：异常实例指向URLSearchParam关联对象，但业务代码未直接使用该类

当前运行环境版本：

• NodeJS: 16.14.2
• Jest: 27.5.1
• jest-serial-runner: 1.2.0

定位步骤 #

按优先级从高到低执行排查：

1. 先缩小问题范围：Jest启动时追加--logHeapUsage参数，逐测试文件、逐用例打印内存占用，定位内存出现阶跃式上涨对应的具体测试文件/用例，避免全量排查的无效工作量。
2. 排查重复字符串来源：在堆快照中选中重复的序列化字符串条目，切换到Retainers（保留路径）视图，向上追溯持有该字符串引用的父级调用链。这类重复字符串90%以上场景来自三类逻辑：Jest自带的测试结果序列化逻辑、接口测试库（如supertest）反复序列化请求/响应体、模块加载时反复执行JSON.parse读取静态资源文件。
3. 排查countries-list异常占用：该库的全量国家静态数据会在首次require时全量加载到内存，如果测试逻辑中频繁调用jest.resetModules()、jest.isolateModules()重置模块缓存，会导致该库被重复加载，多份全量静态数据同时驻留内存。直接全局搜索测试代码中模块重置逻辑的调用位置，确认是否存在重置后重复引入该依赖的问题。
4. 排查JSBufferData异常占用：NodeJS 16.x中URLSearchParams为全局内置对象，无需额外引入，未释放的关联Buffer通常来自三类场景：未关闭的HTTP服务/连接持续持有请求query解析上下文、Jest worker进程通信时的参数序列化缓存、接口测试库构造请求时生成的临时query对象未被释放。重点检查测试用例中的资源回收逻辑即可。

修复方案 #

Jest配置层优化 #

• 在jest.config.js中添加workerIdleMemoryLimit: '512MB'配置，长时运行测试时，worker进程内存达到阈值会自动重启回收内存，适配集成测试的长运行场景。
• 避免在全局afterEach钩子中无差别调用jest.resetModules()，如果必须使用模块重置逻辑，将countries-list这类大体积静态依赖在测试setup文件中提前全局引入，避免重复加载生成多份实例。
• 使用jest-serial-runner串行跑测试时，关闭不必要的测试结果全量序列化配置，减少重复字符串生成。

业务代码与测试逻辑修正 #

• 所有集成测试中启动的HTTP服务实例、数据库连接、缓存连接，必须在afterAll钩子中调用close()方法显式终止，未关闭的长连接会持续持有请求上下文关联的Buffer、参数对象，无法被GC回收。
• 使用接口测试工具发请求时，不要在测试用例中持久持有完整响应对象引用，断言完成后及时解除引用，避免大体积响应体长期驻留内存。
• 业务代码中使用countries-list时，不要每次调用都深拷贝/全量解构导出的国家数据，按需查询对应字段即可，减少无意义的对象复制。

验证方法 #

• 从单测试文件运行开始，逐份增加运行的测试文件，结合--logHeapUsage输出的内存数据定位内存拐点对应的逻辑。
• 对比相邻两份堆快照的增量对象（Allocation Sampling视图），仅关注两次快照之间新生成且未被回收的对象，排除测试初始化阶段加载的常驻内存对象的干扰。

内容的提问来源于stack exchange，提问作者uday8486