如何自己检查NodeJS的代码是不是存在内存泄漏

Posted 2023-04-06

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何自己检查NodeJS的代码是不是存在内存泄漏相关的知识，希望对你有一定的参考价值。

参考技术A

内存泄露的检测

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 hd;memwatch.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)支持的版本在这个分支

如何确定我的 android 应用程序是不是存在内存泄漏？

【中文标题】如何确定我的 android 应用程序是不是存在内存泄漏？【英文标题】：How can I determine if my android app has memory leak?如何确定我的 android 应用程序是否存在内存泄漏？ 【发布时间】：2012-06-19 08:46:42 【问题描述】：

我浏览了整个 internet\goolge\***，但找不到完整而简单的指南，可以向我解释如何找到我的 android 应用程序是否存在内存泄漏。任何人都可以向我解释如何做，或者更好地给我一个很好的指导吗？

我的应用程序收集有关电池的数据并将其保存到手机上的数据库。每次电池发生变化时 (ACTION_BATTERY_CHANGED)，我都会检查电池百分比是否发生变化，在这种情况下，我会保存一些数据。

这个应用程序占用 (25-30)MB RAM 我认为这对于如此简单的应用程序来说太多了。我怀疑它有内存泄漏。

【问题讨论】：

【参考方案1】：

当我遇到和你一样的问题时，我发现了 LeakCanary。它有助于在调试构建的运行时检测内存泄漏，并为堆栈跟踪历史提供舒适的 UI。在这里，您可以阅读有关此用于检测内存泄漏的工具的更多信息以及其他一些对 Android 开发有用的提示：http://cases.azoft.com/4-must-know-tools-for-effective-android-development/。希望它适用于您和其他移动开发者！

【讨论】：

【参考方案2】：

通常，如果您使用应用程序并且它正在积累内存

12 MB ... 13.5 MB...15 MB ...想象一下积聚湿气的云...等等

如果您看到这种模式，则表明您的应用存在内存泄漏。

另一种可能性是您没有泄漏，但您只是使用了太多对象或太大的对象，或者您没有充分利用对象。考虑到位图非常昂贵，因此在内存和资源有限的环境中处理位图可能不是那么简单。

【讨论】：

【参考方案3】：

你可以使用 MAT

这是一个非常好的工具，可以提供非常详细的项目报告，其中包含与内存泄漏相关的基本信息

Android 中的 MAT

http://android-developers.blogspot.in/2011/03/memory-analysis-for-android.html