【发布时间】:2015-05-15 07:46:36
【问题描述】:
我有一个关于使用 Chrome 的开发人员工具调试单页 Web 应用程序中的内存泄漏的问题。
根据 Google 的 documentation,在拍摄堆快照后,您会看到红色和黄色分离的 DOM 节点。黄色节点是那些仍然被 JavaScript 引用的节点,并且有效地代表了泄漏的原因。红色节点在 JavaScript 中没有直接引用,但它们仍然“活跃”——可能是因为它们是黄色节点的 DOM 树的一部分。
通过深入研究堆快照中的所有黄色节点并找到我们的代码中仍然存在对它们的引用,我已经能够修复几个内存泄漏。但是,现在我遇到了一个不知道如何处理的情况:只有红色节点出现在我的堆快照中!
如果没有对这些节点的 JavaScript 引用,还有哪些其他原因导致它们不会被垃圾回收?另外,为什么它说有 155 个条目,但只显示 60 个?我想知道 Chrome 是否根本没有显示一个或多个黄色节点:
【问题讨论】:
-
你在你的代码中使用过
eval()吗? -
您是否查看了有关这些 DOM 元素的更多详细信息,以了解它们是哪些 DOM 元素,也许这可以让您了解哪些代码会引用它们。让一些人失望的参考来源之一是您已经完成但由于某种原因仍然存在的闭包。
-
在快速搜索项目后,我发现我们正在使用的几个第三方库(require.js、history.js、pubnub.js)确实会调用
eval()。现在我假设问题不在于这些库,但你为什么要在这种情况下询问eval()? -
我认为它可能会造成闭包泄漏,因为当您在永久保留的函数中调用
eval时(比如事件处理程序),JS 引擎不会能够清理处理程序关闭的变量,因为它不知道 eval'd 字符串是否会引用其中一个。但现在我想起来了,这仍然需要一个变量引用......所以我不太确定。 -
@jfriend00 我想你可能正在做一些事情,但我已经用尽了我能找到的所有相关闭包,问题仍然存在。我仍然想知道为什么 Chrome 说有 155 个条目,但只显示 60 个。对于其他大型 DOM 树,底部总是有一个按钮,上面写着“显示 100 更多”(或类似的东西)。
标签: javascript memory-leaks garbage-collection google-chrome-devtools