我正在对配置页面中出现的内存泄漏问题进行故障排除。该页面用于更改我们服务的配置并显示健康诊断。这意味着我们定期查询服务以获取配置和检测信息(通常我们使用 30 秒的查询间隔，但为了排除故障，我以 100 毫秒的间隔进行查询)。我们依赖于 knockoutjs、datajs、jquery 和 spinjs。
我发现，如果我以 100 毫秒的查询间隔将页面打开一整夜，Chrome 浏览器选项卡的专用字节会从大约 50MB 增加到 335MB。我有四页关于这个问题，但在我的故障排除工作中我专注于一页。使用 chrome://memory-redirect/我可以看到页面(进程 ID 26148)内存。
然而，JavaScript 堆内存在同一时期似乎持平于 3.6MB。使用 Chrome 中的堆分析工具，它显示我所有的对象分配都被垃圾收集。
上图中灰色的allocations表示对象已经被GC清理掉了。
内存时间线也是不变的。
我还强制了两次 GC，并确认两次 GC 之间文档、节点和监听器的数量是恒定的。
我的问题是:
- 不属于 JavaScript 堆的正在使用的进程内存在哪里？
- 鉴于我们的 JavaScript 堆内存是平坦的，额外的内存是否可能是由我们的 JavaScript 代码引起的内存泄漏？
感谢大家的帮助!
最佳答案
您正在比较苹果和橘子 - 子堆和整个应用程序内存中的垃圾收集内存。
您已经使用 Chrome 检查了 JavaScript 堆，并找到了表明应用程序的 JavaScript 部分运行正常的证据。
您还使用了一个工具来监控 Chrome 本身的全局内存使用情况。这是 Chrome 用于任何任务的所有内存，包括与您的应用程序不直接相关但与浏览器本身的功能相关的任务。
也许您发现了一个在 Chrome 内部触发内存泄漏的用例？
或者这可能不是内存泄漏，而是 Chrome 使用的非垃圾收集内部堆中的内存碎片？
根据这个web page Chrome 是用 C、C++、Java、JavaScript 和 Python 的混合体编写的。这意味着我们有用于 C 和 C++ 的确定性内存分配器，以及用于 Java、JavaScript 和 Python 的三种不同类型的垃圾收集堆。坏消息:当涉及到垃圾收集时，Python 对整数的处理在内存使用方面并不是那么友好(我上次检查是几年前的事了，也许他们已经改进了它)。
但我已经让 Chrome session 运行了数周而没有出现问题。所以我确实想知道发生了什么。
您没有说明您使用的是哪个操作系统，但如果您使用的是 Microsoft Windows，那么您可以使用 C++ Memory Validator在 Chrome 运行时检查每个分配的位置(完整的调用堆栈、多少字节等)(从 C++ 内存验证器启动 Chrome，加载你的应用程序，让它完成它的事情然后转到 Memory选项卡并单击刷新 - 它将显示所有可以跟踪的实时分配 - 任何静态链接的堆都将无法跟踪，因为您没有允许它们被 Hook 的符号)。好的，您没有使调用堆栈可读的符号，但您仍然可以识别发生在同一位置的分配。这可能会为您提供有关泄漏/碎片原因的线索，以便您可以将此报告给 Chrome 开发人员以进行更深入的研究。
你在 Firefox 中有同样的行为吗？如果您可以使用 C++ Memory Validator 执行我建议的操作，但在您自己构建的 Firefox 版本上执行 - 您将拥有符号和源代码，并确切知道问题出在哪里。
免责声明。我是 C++ Memory Validator 的设计者。
关于JavaScript 堆内存是不变的，但是浏览器进程私有(private)字节在增长。内存差异从何而来？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23838249/