如何在分析器中发现内存泄漏？
我制作了一个 AIR/Flex 应用程序，我让几个人测试了它，每个人都报告说，让它运行一段时间后，它会使所有机器运行速度非常慢。 一开始它运行良好，所以这一定是某个地方的内存泄漏。 我对此使用了探查器，唯一显示使用大量内存的是 MethodQueueElement，它不是我编写的类，我不知道它的作用，我假设它的一部分Flex 框架。 我不熟悉使用探查器，所以我不确定我应该看什么，这是唯一一个“内存”很高的类，它说它有超过 100,000 个实例。 如果这是我的问题，我能做些什么来解决它？ 我什至不知道这个类是做什么的，也不知道它是如何实例化的。
谢谢
I have an AIR/Flex app I made, I have a few people testing it and everyone is reporting that after leaving it running for a while, it is making all there machines run very slow. It runs fine at first so this must be a memory leak somewhere. I used the profiler on this and the only thing that shows as using a substantial amount of memory is MethodQueueElement which is not a class I wrote, and I have no idea what it does, I am assuming its part of the Flex framework. I am not familiar with using a profiler so I am not sure what all I shuld be looking at, that was the only class that was high on "memory" and it said it had over 100,000 instances. If this is my problem what can I do to fix it? I do not even know what this class does or anything about how it gets instantiated.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MethodQueueElement 类是 mx.core.UIComponent 类的内部类。
它用于表示已通过 callLater 调用排队的方法调用。
callLater 方法是 UIComponent 公共接口的一部分，因此要么在代码中调用它，要么由框架调用它（例如在 UIComponent.setFocus 中发生的情况）
要释放所有 MethodQueueElement 实例，UIComponent 会替换当前数组MethodQueueElements 被一个新的（空）的。 （在 callLaterDispatcher2 方法中）因此，造成内存泄漏的唯一方法是防止调用 callLaterDispatcher2 。
要调试此问题，您可以开始在方法 callLater 中设置断点（当您的应用程序运行时）（这里创建了您的实例，因此它总是被调用，请查看此处的堆栈跟踪！），callLaterDispatcher2（我想它是不会被调用），并检查 UIComponentGlobals.callLaterSuspendCount 是否 != 0，这可能是 callLaterDispatcher2 没有被调用的原因。
如果是后者，我怀疑您有补间或其他东西调用 UIComponent.suspendBackgroundProcessing 但随后不调用resumeBackgroundProcessing（因为在到达resumeBackgroundProcessing 调用之前出现异常终止代码，例如）
The MethodQueueElement class is an internal class of the mx.core.UIComponent class.
It is used to represent on method call that has been enqueued by a callLater call.
The callLater method is part of the public interface of UIComponent, so either you call it in your code, or it is beeing called by the framework (as it happens in UIComponent.setFocus e.g.)
To free all MethodQueueElement instances, UIComponent replaces the current array of MethodQueueElements by a new (empty) one. (in the callLaterDispatcher2 method) So the only way to make a memory leak out of it is, to prevent callLaterDispatcher2 from beeing called.
To debug this, you can start to set breakpoints (while you app is running) in the methods callLater (here your instances get created, so somehow it gets called all the time, look at the stacktrace here!), callLaterDispatcher2 (i suppose it wont get called), and check whether UIComponentGlobals.callLaterSuspendCount is != 0, which could be the reason callLaterDispatcher2 doesn't get called.
Should the latter be the case, i suspect, that you have tweens or something else calling UIComponent.suspendBackgroundProcessing but then not calling resumeBackgroundProcessing (because of an exception terminating the code before reaching the resumeBackgroundProcessing call e.g.)