上下文：
我有一个Node.js应用程序，它的内存似乎非常高，我不知道这是不是内存泄漏，因为它在一定时间段后会减少，但有时在负载较大的情况下，它会持续增加，需要更长的时间才能减少。
因此，通过阅读这些文章和几个视频，我认为我必须堆积快照并分析是什么导致了内存泄漏。
步骤：
1.到目前为止，我已经在本地拍摄了4张快照，以再现内存泄漏。
快照1：800MB快照2：1400MB快照3：1600MB快照4：2000+MB
1.当我将堆转储文件上传到Chrome开发工具时，我看到了很多信息，但我不知道如何继续。
请检查下面的屏幕截图，它说有构造函数[数组]，它有687206的浅大小，列中保留的大小是721414，所以当展开该构造函数时，我可以看到有4097716个构造函数被创建(参见下面附加的第二个屏幕截图)。
问题
1.internal array []是什么意思？为什么会有4097716人被创造出来？
1.如何筛选出由我的应用程序创建的构造函数，并向我显示该构造函数，而不是某个System/V8引擎构造函数？
1.在同一个屏幕截图中，其中一个构造函数使用了全局变量tenantRequire函数，这是一些地方内部使用的自定义全局函数，而不是普通的Node.js require，我看到这个变量在所有构造函数中都有，比如“数组”、“对象”。这是全局租户请求代码以供参考。它只是打了补丁，需要使用try Catch函数。这是否以某种方式导致了内存泄漏？
1.参考截图3，[string]构造函数，270303848为浅尺寸。当我展开它时，它显示了Node.js加载的模块。问题是，为什么这个函数占用这么大的空间？&为什么在那个字符串构造函数中重复使用我的Lapash模块？
1条答案
按热度按时间qacovj5a1#
如果不太了解你的应用程序和导致高内存使用率的操作，很难判断可能是什么问题。您使用了哪个工具来记录堆快照？录制快照时，您执行的操作顺序是什么？你能在你的问题中加入这一信息吗？
几点备注
您用
node.js标记了问题并显示了Chrome DevTools。没关系。您完全可以获取Node.js应用程序的堆快照并在Chrome DevTools中进行分析。但由于Node.js和Chrome都使用相同的JS引擎(V8)和相同的垃圾收集器(Orinoo)，所以对于阅读问题的人来说，这可能会有点令人困惑。为了确保我理解正确：问题出在Node.js应用程序中，而不是浏览器应用程序中。而您使用Chrome只是为了分析堆快照。对吗？此外，您还写道，您拍摄快照是为了“重现”内存泄漏。这是不对的。您执行了一些您认为会导致高内存使用率的操作，记录了一个堆快照，然后将该快照加载到Chrome DevTools中以“观察”假定的内存泄漏。
先跟踪后配置文件
每次您怀疑有性能问题时，首先应该使用跟踪来了解您的应用程序中哪些函数有问题(即速度慢、创建了大量必须进行垃圾回收的对象等)。然后，当你知道要关注哪些功能时，你就可以分析它们了。
尝试这些可视化工具
有一些工具可以帮助您跟踪/分析您的应用程序。看看FlameScope(一款Web应用程序)和node-clinic(一套工具)。也有Perfetto，但我认为它是针对Chrome应用程序的，而不是Node.js应用程序。
我也强烈推荐V8 blog。