内存泄露的检测

npm模块 memwatch 是一个非常好的内存泄漏检查工具，让我们先将这个模块安装到我们的app中去，执行以下命令：

npm install --save memwatch

然后，在我们的代码中，添加：

var memwatch = require('memwatch')memwatch.setup()

然后监听 leak 事件

memwatch.on('leak', function(info) {

console.error('Memory leak detected: ', info)})

这样当我们执行我们的测试代码，我们会看到下面的信息：

{

start: Fri Jan 02 2015 10:38:49 GMT+0000 (GMT),

end: Fri Jan 02 2015 10:38:50 GMT+0000 (GMT),

growth: 7620560,

reason: 'heap growth over 5 consecutive GCs (1s) - -2147483648 bytes/hr'}

memwatch发现了内存泄漏！memwatch 判定内存泄漏事件发生的规则如下：

当你的堆内存在5个连续的垃圾回收周期内保持持续增长，那么一个内存泄漏事件被派发

了解更加详细的内容，查看 memwatch

内存泄漏分析

使用memwatch我们发现了存在内存泄漏，这非常好，但是现在呢？我们还需要定位内存泄漏出现的实际位置。要做到这一点，有两种方法可以使用。

memwatch heap diff

通过memwatch你可以得到堆内存使用量和内存随程序运行产生的差异。详细的文档在这里

例如，我们可以在两个leak事件发生的间隔中做一个heap dump：

var hdmemwatch.on('leak', function(info) {

console.error(info)

if (!hd) {

hd = new memwatch.HeapDiff()

} else {

var diff = hd.end()

console.error(util.inspect(diff, true, null))

hd = null

}})

执行这段代码会输出更多的信息：

{ before: {

nodes: 244023,

time: Fri Jan 02 2015 12:13:11 GMT+0000 (GMT),

size_bytes: 22095800,

size: '21.07 mb' },

after: {

nodes: 280028,

time: Fri Jan 02 2015 12:13:13 GMT+0000 (GMT),

size_bytes: 24689216,

size: '23.55 mb' },

change: {

size_bytes: 2593416,

size: '2.47 mb',

freed_nodes: 388,

allocated_nodes: 36393,

details:

[ { size_bytes: 0,

'+': 0,

what: '(Relocatable)',

'-': 1,

size: '0 bytes' },

{ size_bytes: 0,

'+': 1,

what: 'Arguments',

'-': 1,

size: '0 bytes' },

{ size_bytes: 2856,

'+': 223,

what: 'Array',

'-': 201,

size: '2.79 kb' },

{ size_bytes: 2590272,

'+': 35987,

what: 'Closure',

'-': 11,

size: '2.47 mb' },...

所以在内存泄漏事件之间，我们发现堆内存增长了2.47MB，而导致内存增长的罪魁祸首是闭包。如果你的泄漏是由某个class造成的，那么what字段可能会输出具体的class名字，所以这样的话，你会获得足够的信息来帮助你最终定位到泄漏之处。

然而，在我们的例子中，我们唯一获得的信息只是泄漏来自于闭包，这个信息非常有用，但是仍不足以在一个复杂的应用中迅速找到问题的来源（复杂的应用往往有很多的闭包，不知道哪一个造成了内存泄漏——译者注）

所以我们该怎么办呢？这时候该Heapdump出场了。

Heapdump

npm模块node-heapdump是一个非凡的模块，它可以使用来将v8引擎的堆内存内容dump出来，这样你就可以在Chrome的开发者工具中查看问题。你可以在开发工具中对比不同运行阶段的堆内存快照，这样可以帮助你定位到内存泄漏的位置。要想了解heapdump的更多内容，可以阅读这篇文章

现在让我们来试试 heapdump，在每一次发现内存泄漏的时候，我们都将此时的内存堆栈快照写入磁盘中：

memwatch.on('leak', function(info) {

console.error(info)

var file = '/tmp/myapp-' + process.pid + '-' + Date.now() + '.heapsnapshot'

heapdump.writeSnapshot(file, function(err){

if (err) console.error(err)

else console.error('Wrote snapshot: ' + file)

})})

运行我们的代码，磁盘上会产生一些.heapsnapshot的文件到/tmp目录下。现在，在Chrome浏览器中，启动开发者工具（在mac下的快捷键是alt+cmd+i），点击Profiles标签并点击Load按钮载入我们的快照。

我们能够很清晰地发现原来leakyfunc()是内存泄漏的元凶。

我们依然还可以通过对比两次记录中heapdump的不同来更加迅速确认两次dump之间的内存泄漏:

想要进一步了解开发者工具的memory profiling功能，可以阅读 Taming The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools 这篇文章。

Turbo Test Runner

我们给Turbo - FeedHenry开发的测试工具提交了一个小补丁 — 使用了上面所说的内存泄漏检查技术。这样就可以让开发者写针对内存的单元测试了，如果模块有内存问题，那么测试结果中就会产生相应的警告。详细了解具体的内容，可以访问Turbo模块。

结论和其他细节

上面的内容讨论了一种检测NodeJS内存泄漏的基本方法，以下是一些结论：

heapdump有一些潜规则，例如快照大小等。仔细阅读说明文档，并且生成快照也是比较消耗CPU资源的。

还有些其他方法也能生成快照，各有利弊，针对你的项目选择最适合的方式。（例如，发送sigusr2到进程等等，这里有一个memwatch-sigusr2项目）

需要考虑在什么情况下开启memwatch/heapdump。只有在测试环境中有开启它们的必要，另外也需要考虑heapdump的频度以免耗尽了CPU。总之，选择最适合你项目的方式。

也可以考虑其他的方式来检测内存的增长，比如直接监控process.memoryUsage()是一个可以考虑的方法。

当内存问题被探测到之后，你应该要确定这确实是个内存泄漏问题，然后再告知给相关人员。

当心误判，短暂的内存使用峰值表现得很像是内存泄漏。如果你的app突然要占用大量的CPU和内存，处理时间可能会跨越数个垃圾回收周期，那样的话memwatch很有可能将之误判为内存泄漏。但是，这种情况下，一旦你的app使用完这些资源，内存消耗就会降回正常的水平。所以，你其实需要注意的是持续报告的内存泄漏，而可以忽略一两次突发的警报。

memwatch目前仅支持node 0.10.x，node 0.12.x（可能还有io.js)支持的版本在这个分支

首先，检查了代码，发现所有的代码都是用new来分配内存，用delete来释放内存。那么，不能够用一个全程替换，来替换掉所有的new和delete操作符，因为代码的规模太大了，那样做除了浪费时间没有别的任何好处。好在源代码是用C++来写成的，所以，这意味着没有必要替换掉所有的new和delete,而只用重载这两个操作符。对了，值用重载这两个操作符，就能在分配和释放内存之前做点什么。这是一个绝对的好消息。也知道该如何去做。因为，MFC也是这么做的。需要做的是：跟踪所有的内存分配和交互引用以及内存释放。源代码使用Visual C++写成，当然这种解决方法也可以很轻松的使用在别的C++代码里面。要做的第一件事情是重载new和delete操作符，将会在所有的代码中被使用到。在stdafx.h中，加入：

#ifdef _DEBUG

inline void * __cdecl operator new(unsigned int size,

const char *file, int line)

{

}

inline void __cdecl operator delete(void *p)

{

}

#endif

这样，就重载了new和delete操作符。用$ifdef和#endif来包住这两个重载操作符，这样，这两个操作符就不会在发布版本中出现。看一看这段代码，会发现，new操作符有三个参数，它们是，分配的内存大小，出现的文件名，和行号。这对于寻找内存泄漏是必需的和重要的。否则，就会需要很多时间去寻找出现的确切地方。加入了这段代码，调用new()的代码仍然是指向只接受一个参数的new操作符，而不是这个接受三个参数的操作符。另外，也不想记录所有的new操作符的语句去包含__FILE__和__LINE__参数。需要做的是自动的让所有的接受一个参数的new操作符调用接受三个参数的new操作符。这一点可以用一点点小的技巧去做，例如下面的这一段宏定义，

#ifdef _DEBUG

#define DEBUG_NEW new(__FILE__, __LINE__)

#else

#define DEBUG_NEW new

#endif

#define new DEBUG_NEW

现在所有的接受一个参数的new操作符都成为了接受三个参数的new操作符号，__FILE__和__LINE__被预编译器自动的插入到其中了。然后，就是作实际的跟踪了。需要加入一些例程到重载的函数中去，让能够完成分配内存和释放内存的工作。这样来做， #ifdef _DEBUG

inline void * __cdecl operator new(unsigned int size,

const char *file, int line)

{

void *ptr = (void *)malloc(size)

AddTrack((DWORD)ptr, size, file, line)

return(ptr)

}

inline void __cdecl operator delete(void *p)

{

RemoveTrack((DWORD)p)

free(p)

}

#endif

另外，还需要用相同的方法来重载new[]和delete[]操作符。这里就省略掉它们了。

最后，需要提供一套函数AddTrack()和RemoveTrack()。用STL来维护存储内存分配记录的连接表。

这两个函数如下：

typedef struct {

DWORD address

DWORD size

char file[64]

DWORD line

} ALLOC_INFO

typedef list<ALLOC_INFO*>AllocList

AllocList *allocList

void AddTrack(DWORD addr, DWORD asize, const char *fname, DWORD lnum)

{

ALLOC_INFO *info

if(!allocList) {

allocList = new(AllocList)

}

info = new(ALLOC_INFO)

info->address = addr

strncpy(info->file, fname, 63)

info->line = lnum

info->size = asize

allocList->insert(allocList->begin(), info)

}

void RemoveTrack(DWORD addr)

{

AllocList::iterator i

if(!allocList)

return

for(i = allocList->begin()i != allocList->end()i++)

{

if((*i)->address == addr)

{

allocList->remove((*i))

break

}

}

}

现在，在程序退出之前，allocList存储了没有被释放的内存分配。为了看到是什么和在哪里被分配的，需要打印出allocList中的数据。使用了Visual C++中的Output窗口来做这件事情。

void DumpUnfreed()

{

AllocList::iterator i

DWORD totalSize = 0

char buf[1024]

if(!allocList)

return

for(i = allocList->begin()i != allocList->end()i++) {

sprintf(buf, "%-50s: LINE %d, ADDRESS %d %d unfreed ",

(*i)->file, (*i)->line, (*i)->address, (*i)->size)

OutputDebugString(buf)

totalSize += (*i)->size

}

sprintf(buf, "----------------------------------------------------------- ")

OutputDebugString(buf)

sprintf(buf, "Total Unfreed: %d bytes ", totalSize)

OutputDebugString(buf)

}

现在就有了一个可以重用的代码，用来监测跟踪所有的内存泄漏了。这段代码可以用来加入到所有的项目中去。虽然它不会让你的程序看起来更好，但是起码它能够帮助你检查错误，让程序更加的稳定。

一、定位node.js内存漏洞的工具：

工欲善其事必先利其器，在排查时，我们还是需要一些工具来帮忙的。

devTool

这个是今年初出的 Node.js 调试工具，基于 Electron 将 Node.js 和 Chromium 的功能融合在了一起。操作起来比 node-inspector 方便，开放的 Timeline 功能还是比较实用的，虽然不是实时显示。

仅需要 devtool xxx.js，还可以通过 .devtoolrc 来进行参数定制，具体见 GitHub

heapdump + chrome devTool

这个是比较传统的定位内存泄漏的组合。heapdump 可以直接在代码中调用生成内存快照，然后将快照文件导入到 chrome devTool 进行分析，之后操作其实和前者就差不多了。不过，这个方案和前者有一点区别就是，前者实际还是在浏览器环境中，所以生成的内存快照会有一些 DOM 对象的存在，会有一定的干扰。而这个方案，是直接调用底层 V8 的方法，生成的快照只有 Node.js 环境中的对象。

memwatch

这个可以在代码里直接使用，实时检测内存动态，当发生内存泄漏的时候，会触发 ‘leak’ 事件，会传递当前的堆状态，配合 heapdump 有奇效。

二、定位问题：

用 devTool 的可以忽略下面的过程：

打开 Chrome Devtools ，进入到 Profiles 选项卡，点 Load 按钮，加载之前生成的快照。

对于内存快照，有四个视图，Summary，Comparison，Containment，Statistics，这里面常用的是前三个。

在 Summary 视图中，我们可以看到当前快照的全部信息，以及多个快照之间的信息。在列表里显示的都是对象的构造函数名字，可以先忽略被括号包裹的对象，优先观察其他的对象，最后再来看他们。后面的 shallow size 表示的是对象自身的大小，retained size 表示的是对象和它依赖对象的大小，一般是 GC 不可达的。

在 Comparison 视图中，我们可以进行多个快照之间的对比，这个用处比较大，如果我们将前两次快照进行对比，可能比较快速的定位出问题的对象。注意观察 New、Deleted、Delta，如果是内存泄漏的对象，可能是一直在 New，而没有 Deleted。

在 Containment 视图中，我们可以查看整个 GC 路径，当然一般不会用到。因为展开在 Summary 和 Comparison 列举的每一项，都可以看到从 GC roots 到这个对象的路径。通过这些路径，你可以看到这个对象的句柄被什么持有，从而定位问题产生的原因。值的注意的是，其中背景色黄色的，表示这个对象在 Javascript 中还存在引用，所以可能没有被清除。如果是红色的，表示的是这个对象在 Javascript 中不存在引用，但是依然存活在内存中，一般常见于 DOM 对象，它们存放的位置和 Javascript 中对象还是有不同的，在 Node.js 中很少遇见。

---