首先 - 不要使用delete
正如评论之一所建议的那样。设置参考null
是处理东西的正确方法。delete
打破“隐阶级”。要亲自查看,请运行我的示例https://github.com/naugtur/js-memory-demo https://github.com/naugtur/js-memory-demo
Rafe,你在分析器中看到的内容通常很难理解。您在此处发布的内容确实看起来很奇怪,可能是应用程序外部的错误或内存泄漏(浏览器也泄漏),但如果不运行您的应用程序,就很难判断。您的保留树以函数的上下文结束,并且可以通过对该函数或共享上下文的其他函数的引用来保留它。对于分析器来说,它可能太复杂而无法正确可视化。
不过我可以帮助你找出问题所在。
首先,转到开发工具中的“时间轴”选项卡并使用它来观察泄漏发生的时刻。仅选择内存分配并开始录制。经历一个您预计会泄漏的场景。保持蓝色的条是泄漏。您可以在时间轴中选择它们的周围并关注它们的保留树。独立 dom 树中最有趣的元素是红色元素 - 它们是从外部引用的。其余部分被保留,因为树中的任何元素被引用,它都引用了其他所有元素(x.parentNode
)
如果您需要更多详细信息,您可以在分析器中拍摄多个快照,以便您在泄漏原因之前和之后都有一个快照(您通过时间线找到的 - 您现在知道导致泄漏的确切操作)。然后,您可以在探查器中比较它们 - 有一个“比较”视图。这比其他人更容易理解。
您还可以从分析器中保存堆快照并将其发布到网上,以便我们查看。左侧列表中的每个项目都有一个保存链接。
分析内存很困难,实际上需要一些练习和对工具的理解。
你可以练习我演讲中的一些例子:
http://naugtur.pl/pres/mem.html#/5/2 http://naugtur.pl/pres/mem.html#/5/2
但使用内存分析器的真正完整指南是这个文档:
https://developer.chrome.com/devtools/docs/javascript-memory-profiling#looking_up_color_coding https://developer.chrome.com/devtools/docs/javascript-memory-profiling#looking_up_color_coding
更新的链接: https://developers.google.com/web/tools/profile-performance/memory-problems/memory-diagnosis https://developers.google.com/web/tools/profile-performance/memory-problems/memory-diagnosis