这篇文章是由Mozilla的Identity团队带来的 A Node.JS Holiday Season系列文章的首篇，该团队上个月发布了 Persona的第一个测试版本。在开发Persona时我们构建了一系列的工具，包括了从调试，到本地化，到依赖管理以及更多的方面。在这一系列的文章中我们将与社区分享我们的经验和这些工具，这对任何想用node.js建立一个高可用性服务的人都很有用。我们希望您能喜欢这些文章，并期待看到您的想法和贡献。
我们将从一篇关于Node.js的实质性问题：内存泄漏的主题文章开始。我们会介绍 node-memwatch — 一个帮助发现并隔离Node中的内存泄漏问题的函数库。
为什么自寻烦恼？
关于追踪内存泄漏问得最多的问题就是，“为什么要自寻烦恼？”。难道没有更紧迫的问题需要先解决吗？为什么不选择不时地重启服务，或为之分配更多的ＲＡＭ？为了回答这些问题，我们提出了以下三点建议：
１．也许你不在乎不断增长的内存占用，但Ｖ８在乎（Ｖ８是Ｎｏｄｅ运行时的引擎）。随着内存泄漏的增长，Ｖ８对垃圾收集器越来越具有攻击性，这会使你的应用运行速度变慢。所以，在Ｎｏｄｅ上，内存泄漏会损害程序性能。
２．内存泄漏可能触发其他类型的失败。内存泄漏的代码可能会持续的引用有限的资源。你可能会耗尽文件描述符；你还可能会突然不能建立新的数据库连接。这类问题可能在你的应用耗尽内存前很早就会暴露出来，但它仍然会是你陷入困境。
３．最后，你的应用迟早会崩溃，并且在你的应用受到欢迎时肯定会发生。所有人都会在Ｈａｃｋｅｒ Ｎｅｗｓ上嘲笑你，讽刺你，这样你就悲剧了。
溃千里之堤的蚁穴在哪里？
在构建复杂应用的时候，很多地方都可能发生内存泄露。 闭包可能是最广为人知也是最声名狼藉的。因为闭包保留了对其作用域内的东西的引用，而这正是通常的内存泄露之源。
闭包泄露往往只有在有人去寻找它们的时候才能发现。但是在Node的异步世界里，我们随时随地的通过回调函数不停的生成闭包。如果这些回调函数没有在创建后立刻使用，分配的内存就会持续增长，那些看起来没有内存泄露问题的代码也会产生泄露。而这种问题更难发现。
你的应用也可能由于上游代码的问题导致内存泄露。也许你能定位到出现内存泄露的代码，但是你可能只能眼巴巴地盯着你那完美无缺的代码然后困惑于这到底是怎么泄露的！
正是这些难以定位的内存泄露促使我们想要一个node-memwatch这样的工具。传说几个月以前，我们的Lloyd Hilaiel把他自己锁在一个小房间里两天，试着追踪一个在压力测试下变得非常明显的内存泄露问题。（顺便说下，尽请期待Lloyd即将到来的关于负荷测试的文章）
经过两天的努力，他终于发现了Node内核中的元凶：http.ClientRequest中的事件监听器没有被释放。(最终修复这个问题的补丁只有两个但却至关重要的字母)。正是这次痛苦的经历促使Lloyd想要写一个能够帮助查找内存泄露的工具。
内存泄露定位工具
现在已经有许多好用且不断增强的工具用于定位Node.js应用的内存泄露。下面是其中的一些：
上面的这些工具我们都很喜欢，但是没有一个适用于我们的场景。Web Inspector对于开发中的应用非常棒，但是很难用于热部署的场景，尤其是在多服务器和涉及子进程的时候。同样的，在长时间高负载运行中出现的内存泄露也很难复现。像dtrace和libumem这样的工具虽然让人印象深刻，但是不是所有的操作系统都能用。
Enternode-memwatch
我们需要一个跨平台的调试库，当我们的程序可能存在内存泄漏时，它不需要设备告诉我们，并且会帮我们找到哪里存在泄漏。所以我们实现了node-memwatch。
它给我们提供三件东西：
一个‘泄漏'事件发射器
memwatch.on('leak', function(info) { // look at info to find out about what might be leaking });
一个‘状态事件发射器
var memwatch = require('memwatch'); memwatch.on('stats', function(stats) { // do something with post-gc memory usage stats });
一个堆内存区分类
var hd = new memwatch.HeapDiff(); // your code here ... var diff = hd.end();
并且还有一个在测试时很有用处的，可以触发垃圾收集器的功能。好吧，一共四点。
var stats = memwatch.gc();
memwatch.on('stats', ...): Post-GC堆统计