Express/Node.js请求处理后内存占用不下降是否为内存泄漏

1. 观测到的「单次请求涨0.5MB内存、请求结束后内存不立刻回落」是否正常？ #

短时间观测到的该现象大概率是正常表现，别上来就判定是出故障了。
Node.js 依赖 V8 引擎做内存管理，垃圾回收（GC）从来不是实时触发的：只有新生代内存占满、老生代内存占用达到预设阈值时，V8 才会执行对应回收逻辑，请求处理完成后内存不会立刻被释放还给操作系统，属于运行时的正常调度逻辑。
另外系统层面看到的进程内存占用不等于 V8 堆实际使用量：V8 回收堆内无用对象后，也不一定会立刻把空闲内存返还给操作系统，从系统监控面板看内存数值可能会稳定在较高位置，这也属于正常情况。

2. 该现象是否代表存在待修复的内存泄漏？ #

不一定，必须通过压测验证才能下结论，不要仅凭几次请求的内存走势就判定存在泄漏：

• 验证方法：启动服务时增加--expose-gc参数，对同个接口连续发起数千到上万次重复请求，压测间隙主动调用global.gc()手动触发全量垃圾回收，排除GC调度延迟的干扰
• 判定标准：如果手动GC后内存能回落到接近压测前的基准值，且压测到一定量级后内存会在固定区间波动、不会持续线性上涨，就不存在需要修复的内存泄漏；如果手动GC后内存仍然持续线性上涨，最终触发OOM导致进程退出，才是真的存在内存泄漏。
  绝大多数真实内存泄漏都是代码逻辑错误导致的，常见诱因包括：全局对象无限制挂载请求相关数据、闭包长期持有大对象引用、重复注册事件监听器不销毁、无过期策略的缓存无限存储数据、数据库/文件句柄用完不释放等。

3. 问题源于Express框架还是Node.js本身？ #

稳定版的Express框架、Node.js本身均不存在「每次请求固定涨0.5MB内存且永不释放」的通用已知bug，这类问题99%以上的概率是业务代码、第三方引入的中间件导致的，不要直接甩锅给底层框架或运行时。
你可以通过以下步骤快速定位根因：

• 先做对照实验：写一个最简Express服务，只初始化实例、绑定一个直接返回响应的空路由，不加载任何自定义中间件和业务逻辑，用同样的压测方式观测内存走势，如果空服务内存表现正常，就可以直接排除Express和Node本身的问题
• 用Chrome DevTools连接Node.js调试端口，在压测前后分别采集堆快照，对比快照中持续增长的对象类型、引用链路，就能快速定位到持有对象不释放的代码位置
• 逐个排查你引入的第三方中间件、自己写的业务逻辑，重点检查全局变量、闭包、监听器、缓存相关的代码。

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