解决Node.js内存泄漏问题的实战案例

在构建大型Node.js应用时，内存管理是一个常见的挑战。本文将分享我们团队在生产环境中遇到的一个Node.js内存泄漏问题，以及我们是如何一步步排查和解决的。

问题背景

我们的应用是一个基于Express的REST API服务，日常处理约50万请求。在一次版本更新后，我们观察到服务器的内存使用率持续上升，最终导致服务崩溃。重启服务后，问题依然存在，这明显是内存泄漏的征兆。

排查过程

1. 初步分析

首先，我们使用Node.js内置的process.memoryUsage()方法监控内存使用情况：

setInterval(() => {
  const memUsage = process.memoryUsage();
  console.log(`Memory usage: ${JSON.stringify(memUsage)}`);
}, 60000); // 每分钟记录一次

通过日志分析，我们发现heapUsed值持续增长，这确认了内存泄漏的存在。

2. 使用堆快照分析

接下来，我们使用Node.js的堆快照工具来分析内存使用情况：

const heapdump = require('heapdump');

// 在适当的时机生成堆快照
process.on('SIGUSR2', () => {
  heapdump.writeSnapshot(`./heapdump-${Date.now()}.heapsnapshot`);
});

我们在不同时间点生成了多个堆快照，然后使用Chrome DevTools的Memory面板进行分析。

3. 发现问题根源

通过比较不同时间点的堆快照，我们发现有大量的UserSession对象没有被正确释放。进一步分析代码，我们定位到问题出在一个缓存实现上：

// 有问题的代码
const sessionCache = {};

function getUserSession(userId) {
  if (!sessionCache[userId]) {
    sessionCache[userId] = createNewSession(userId);
  }
  return sessionCache[userId];
}

这段代码的问题在于，我们创建了一个永不清理的缓存。随着用户数量增加，缓存中的会话对象越来越多，最终导致内存泄漏。

解决方案

我们决定使用带有过期时间的LRU（最近最少使用）缓存来替代简单的对象缓存：

const LRU = require('lru-cache');

const sessionCache = new LRU({
  max: 1000, // 最多存储1000个会话
  maxAge: 1000 * 60 * 30 // 30分钟过期
});

function getUserSession(userId) {
  if (!sessionCache.has(userId)) {
    sessionCache.set(userId, createNewSession(userId));
  }
  return sessionCache.get(userId);
}

此外，我们还添加了以下改进：

1. 实现了定期清理机制，主动释放不再需要的资源
2. 添加了内存使用监控和告警系统
3. 在关键API路径上添加了性能监控

效果验证

实施上述解决方案后，我们对服务进行了压力测试和长时间运行测试。结果表明，内存使用率保持在稳定水平，不再出现持续增长的情况。

以下是优化前后的内存使用对比：

优化前：初始 200MB -> 12小时后 1.5GB -> 24小时后 OOM崩溃
优化后：初始 200MB -> 12小时后 250MB -> 24小时后 260MB (稳定)

经验总结

通过这次排障经历，我们总结了以下经验：

1. 谨慎使用全局缓存：确保缓存有大小限制和过期策略
2. 定期监控内存使用：建立监控系统，及早发现问题
3. 使用合适的工具：熟悉Node.js的性能分析工具，如heapdump、clinic.js等
4. 代码审查很重要：在代码审查中特别关注可能导致内存泄漏的模式
5. 循序渐进地排查：从简单的监控开始，逐步深入分析

希望这个实战案例能帮助你在遇到类似问题时更快地定位和解决。如果你有其他处理Node.js内存泄漏的经验，欢迎在评论区分享！