【问题标题】:Why doesn't my Chrome Profiler show proper retaining paths for my objects, and why are my objects never released?为什么我的 Chrome Profiler 没有为我的对象显示正确的保留路径,为什么我的对象从未被释放?
【发布时间】:2012-03-19 03:55:46
【问题描述】:

我正在尝试调试我的 web 应用程序中的内存泄漏。

我拍摄堆的快照并比较不同的堆。

我发现我的一些对象在某处被引用。 但是,我的所有对象都通过看起来在我内部的对象保留,例如:

如您所见,这个 SectionNavView 对象被我创建的几个方法引用:cleanUp、hide、isShown 等,使用我的局部变量 that,但这些方法被引用来自我无法控制的东西:idToWrappedObject。有时,还有另一个中介 - injectedScript 对象。

如果我的对象只是从内部 V8 引用中被引用,难道不应该在分析器在其 GC 期间拍摄快照之前释放它们吗?

【问题讨论】:

  • 如果它们被你无法控制的东西引用,它可能有你无法删除的循环引用。
  • 如果下面的答案回答了您的问题,Stack Overflow 的工作方式,您会“接受”这个答案。详情:stackoverflow.com/help/someone-answers

标签: javascript debugging google-chrome memory-leaks profiler


【解决方案1】:

这仅仅意味着您使用了console.log。因此,VM 会保留对您的对象的引用,以便您稍后检查它们。您可以停止使用控制台,也可以在每次拍摄堆快照时将其清除。

您可以通过以下步骤重现它:

  1. 打开新标签
  2. 打开控制台(如果有的话,清除它)
  3. 获取堆快照 1
  4. 在控制台中输入console.log({ foo:'bar' })
  5. 获取堆快照 2
  6. 清除控制台
  7. 获取堆快照 3

然后查看结果:

  1. 打开快照2和快照1的比较视图;你会找到{ foo: 'bar' } 对象

  2. 打开快照3和快照2的比较视图;你会发现同一个对象现在显示的增量为 -1,这意味着它在你清除控制台后被垃圾收集

最后,您可能还会在 _idToWrappedObjectInjectedScript 旁边的保留树路径中看到“全局句柄”和“GC 根”。我不确定这如何适用于 GC 根的定义,但清除控制台确实允许垃圾收集。

【讨论】:

  • 我什至没有考虑 console.log 可能对堆快照有任何影响的可能性。为此+1。将重新测试并随时通知您。太棒了。
  • 非常感谢。我刚刚清除了我认为感谢你的最后一次内存泄漏。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-04-17
  • 1970-01-01
  • 1970-01-01
  • 2011-09-24
  • 1970-01-01
  • 2021-09-16
相关资源
最近更新 更多