具有 0 条路径的 Flex 徘徊对象
我的应用程序泄漏了一个名为 GraphViewer 的可视组件。每次用户更改图形时，都会创建一个新的查看器，并将旧的查看器从舞台上删除并丢弃。然而记忆似乎在泄漏。当我使用 Flex 探查器跟踪徘徊对象时，它显示 GraphViewer 实例确实存在泄漏，但是当我检查徘徊查看器的对象引用时，我发现所有这些查看器（除了一个）都有 0 个到 GC 根的路径。
我在 GC 后拍摄内存快照，然后更改图形（创建新查看器）N 次。然后我进行 GC，拍摄另一个快照并查看徘徊对象。我看到 N 个 GraphViewer 对象徘徊，但其中 N-1 个实际上有 0 条路径，只有一个有任何实际引用它的东西。
当无法从 GC 根访问对象时，为什么 Flex 探查器将对象显示为徘徊？ Flex 分析仪可靠吗？
My application is leaking a visual component called GraphViewer. Every time the user changes graphs a new viewer is created and the old one is removed from the stage and discarded. Yet memory seems to leak. When I use the Flex profiler to track loitering objects it shows that GraphViewer instances indeed leak, but when I examine the object references of the loitering viewers I see that all of them (except one) have 0 paths to GC root.
I take a memory snapshot after GC and then change the graph (create a new viewer) N times. Then I do GC, take another snapshot and look at loitering objects. I see N GraphViewer objects loitering, but N-1 of them actually have 0 paths and only one has anything actually referencing it.
Why is the Flex profiler showing objects as loitering when they cannot be reached from the GC root? Is the Flex profiler reliable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，为什么当新数据到达时需要创建组件的新实例？看起来有点浪费。重用实例比创建新实例更好。
其次，如果没有代码，很难回答您的问题，但通常视图组件保留在内存中的原因是因为有人仍然引用它，或者事件侦听器尚未正确清理。
最后，GC 中存在一个已知的错误已经有一段时间了（虽然我最近没有测试过它；自从我可以重现以来已经大约一年了），其中大内存“岛”（想象一个非常大的模块）获胜无法正确清理，因为 GC 的往返算法不会认为它已与其余部分断开连接。为了缓解这种情况，您可能需要实现一个 IDisposable 接口，其中您的“父”视图在从舞台中删除之前调用销毁函数（然后在整个组件及其子组件中传播以进行销毁）。
祝你好运。
First off, why do you need to create a new instance of your component when new data arrives? Seems a bit wasteful. It's better to reuse an instance than to create a new one.
Second, it's hard to answer your issue without code, but often times the reason why a view component is kept in memory is because someone either still have a reference to it or an event listener hasn't been cleaned properly.
And lastly, there has been a known bug in the GC for some time now (though I haven't tested it recently; been about a year since I could reproduce) where large memory 'islands' (think of a very large module) won't clean up properly because the round trip algorithm for the GC won't figure that it's disconnected from the rest. To alleviate that, you might want to implement an IDisposable interface where your 'parent' view calls a destroy function before removing from stage (which then propagates throughout the component and it's children to destroy as well).
Good luck.