关于Node.js应用内存泄漏，我是这样排查和定位的#

本宫就知道，总有那么些不省心的，非要把自己的Node应用搞得像皇上的后宫一样，人丁（对象）兴旺，最后却闹得个空虚（内存）至死，还跑来问本宫怎么办。得，本宫今天就发发善心，教教你们这些小蹄子，怎么给自家的Node应用查体，把那些偷偷吃内存的“妖孽”给揪出来。

一、症状？本宫一看便知

别等到你们的应用慢得像皇上的御书房批折子一样，响应拖沓，或者干脆甩出个“JavaScript heap out of memory”的大白脸，才想起来喊疼。本宫告诉你，那已经是病入膏肓了。症状要早看！比如，你重启一次服务，能撑好久；但随着请求变多，那内存就跟皇上见了新选秀似的，只进不出，一路飙升，最后稳稳卡在一个高位，死活不肯降下来。或者，你明明没多少并发，node进程却跟吃了十全大补丸似的，内存占用高得离谱。有这些迹象？呵，那你家“后院”指定是起火了。

二、本宫见过的蠢操作，你们可别学

在教你怎么“捉奸”之前，本宫先帮你们盘盘道，看看自己是不是就是那个“蠢操作”本蠢。

第一蠢，闭包用得那叫一个深情，把外头的大对象紧紧搂在怀里，死活不撒手。你以为这是深情？这是内存的坟头草！一个本该完事儿就回收的函数，被你一个闭包给“钉”在了内存里，日积月累，可不就炸了？

第二蠢，把全局变量当自家后花园，什么破烂都往里堆。process.env都不够你塞的，非得搞个全局大对象，里面又是配置又是缓存，还觉得特机灵。皇上都不带这么挥霍国库的！

第三蠢，事件监听器，加的时候一时爽，忘了解绑火葬场。尤其是那些跟请求生命周期绑定的事件，你光管杀不管埋，监听器堆积如山，回调函数里引用着一堆上下文，内存想跑都跑不掉。

第四蠢，缓存没个谱。是，本宫知道加缓存显得你技术好，但你那个缓存没设置上限，没设置过期策略，是打算把全紫禁城的数据都搬进来吗？Redis看了都得给你递根烟，说句“大哥，悠着点”。

三、御赐法宝，都给本宫用起来

抱怨完，该给你们发武器了。第一件法宝，Node自带的process.memoryUsage()。这玩意儿就像给你配了个贴身太医，随时能号脉。在关键路径上打印一下，看看heapUsed和heapTotal的变化趋势。如果它跟脱缰的野马一样只增不减，哼，你家有贼了。

第二件，Chrome DevTools。别以为它只能调页面，连上你的Node进程（用--inspect参数），它能让你看到内存堆的3D视图。那些数量异常的、占着内存不放的“可疑对象”，在视图里就跟黑夜里的萤火虫一样，藏不住。谁被大量实例化了？谁的Size大得离谱？一目了然。抓到一个，顺藤摸瓜，必有收获。

第三件，heapdump模块。这个是更直接的。在你觉得内存差不多快爆的时候，触发它，生成一个.heapsnapshot文件，然后用Chrome DevTools打开分析。这叫“现场取证”，那些“凶手”（泄漏的对象）和“凶器”（被引用的路径）全在里面。对比两个时间点的快照，新出来的、没被回收的就是你的重点怀疑对象。

四、实战：捉它个现行

光说不练假把子。步骤本宫给你码好了，照做就行：

1. 启动时带上侦探：node --inspect your-app.js，或者直接用heapdump模块埋好点。
2. 给你的应用来一轮压力测试，模拟正常或高峰请求。
3. 观察内存。用process.memoryUsage()看个大概，如果趋势不对，就准备动手抓快照。抓两次，一次在内存相对正常时，一次在它明显飙升后。
4. 打开Chrome，访问chrome://inspect，找到你的Node进程，点“inspect”。
5. 在Memory面板，加载你抓到的heap snapshot文件。
6. 重点来了！ 用Comparison视图，对比两个快照。找“#Delta”和“Size Delta”大的那些对象。看看它们的Constructor名字，是不是眼熟？然后点击它，下面会显示“Retainers”，这就是引用链。顺着这条链往上找，看看是谁一直死死拽着它不放手，导致垃圾回收器（GC）想收都收不走。那个“谁”，就是你的罪魁祸首。

五、收尾，给本宫记住了

排查内存泄漏，就跟审案子一样，得有耐心，有方法。别一上来就瞎猜，要相信工具，抓住证据链。修复的时候，记住本宫的话：谁申请，谁释放；用完就扔，别留后患；边界要清，缓存要限。

本宫今天说得口干舌燥，要是还有哪个小迷糊照着做了还找不着，那就不是本宫没教，是你的代码跟皇上的奏折一样，根本没救了。自己再从头捋一遍，把本宫提到的每一个点都对照检查。行了，本宫乏了，退下吧。