具有 0 个路径的 Flex 游荡对象 [英] Flex loitering objects with 0 paths

问题描述

我的应用程序泄漏了一个名为 GraphViewer 的可视化组件.每次用户更改图形时，都会创建一个新的查看器，而旧的查看器会从舞台上移除并丢弃.然而，内存似乎泄漏了.当我使用 Flex 探查器跟踪游荡对象时，它显示 GraphViewer 实例确实泄漏，但是当我检查游荡查看器的对象引用时，我发现所有这些(除了一个)都有 0 个通往 GC 根的路径.

我在 GC 后拍摄内存快照，然后更改图表(创建新查看器)N 次.然后我做 GC，拍摄另一个快照并查看游荡对象.我看到 N 个 GraphViewer 对象在游荡，但其中 N-1 个对象实际上有 0 个路径，并且只有一个对象实际引用了它.

当无法从 GC 根访问对象时，为什么 Flex 分析器将对象显示为闲置?Flex 分析器可靠吗?

解决方案

首先，当新数据到达时，为什么需要创建组件的新实例?好像有点浪费.重用一个实例比创建一个新实例要好.

第二，没有代码就很难回答你的问题，但很多时候视图组件被保存在内存中的原因是因为有人仍然引用它或者事件监听器没有被正确清理.

最后，GC 中存在一个已知的错误已经有一段时间了(尽管我最近没有测试过它；自从我可以复制大约一年以来)，其中大内存孤岛"(想想一个非常大的模块)不会正确清理，因为 GC 的往返算法不会认为它与其余部分断开连接.为了缓解这种情况，您可能需要实现一个 IDisposable 接口，其中您的父"视图在从舞台移除之前调用一个销毁函数(然后在整个组件中传播，并且它的子组件也要销毁).

祝你好运.

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?

解决方案

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.

这篇关于具有 0 个路径的 Flex 游荡对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！