我开始遇到严重的问题,垃圾收集器部分地捡起来了,但仍然保留了大部分对象并在后台运行而没有引用:
m_win = new MyWindow(arr);
m_win.open();
m_win.addEventListener(Event.CLOSE, onClose);
.
.
.
private function onClose(pEvent:Event):void
{
m_win.removeEventListener(Event.CLOSE, onClose);
m_win.close();
m_win = null;
// RAM usage for m_win is only reduced about 20-40%. I can see the garbage
// collector has run as a result of that reduction, but the other 60-80% are
// a serious problem.
}
这是我添加到m_win的唯一事件监听器,这是我的代码对m_win的唯一引用。 MyWindow基本上是一个独立的AIR项目(虽然它嵌套在与其自己的Main类不同的类中,以使其适用于此场景;否则相同)。 MyWindow有NetConnections,NetStreams等,它们会在垃圾收集器运行后保持活动状态。
所以我尝试的第一件事就是进入并断开其NetConnections和NetStreams。但那没用。然后我遇到了这些博客:
http://tomgabob.blogspot.com/2009/11/as3-memory-management.html
我在另一个博客中找到了另一个博客的链接,这个博客遇到了同样的问题:假设AS3的垃圾收集器发现一个已经达到临界质量的“孤岛”(根据我的经验,可能是30 MB?),它只是拒绝对它做任何事情。所以我按照这个人的建议去了,至少试图清除每个引用,删除每个事件监听器,在必要时调用removeAllElements()和/或removeChildren(),并在MyWindow中手动调用“析构函数”函数,唯一的例外是没有真正用于m_win的Main类。
除非我搞砸了,否则它不起作用。但是,即使我遗弃了几块石头,它仍然应该让岛上的碎片绰绰有余。我一直在研究这个问题的其他原因和解决方法,并尝试过其他的东西(比如手动告诉垃圾收集器运行),但没有任何东西正在清理混乱。唯一有效的方法是在出路时断开NetConnection / NetStream的东西,但仍然没有收集好的25-30 MB。如何解决这个问题?谢谢!
编辑:鉴于Adobe在http://www.adobe.com/devnet/actionscript/learning/as3-fundamentals/garbage-collection.html的声明:
"GCRoots are never garbage collected."
和
"The MMgc is considered a conservative collector for mark/sweep. The MMgc can't
tell if certain values in memory are object pointers (memory addresses) or a
numeric value. In order to prevent accidentally collecting objects the values
may point to, the MMgc assumes that every value could be a pointer. Therefore,
some objects that are not really being pointed to will never be collected and
will be considered a memory leak. Although you want to minimize memory leaks to
optimize performance, the occasional leaks that result from conservative GC tend
to be random, not to grow over time, and have much less of an impact on an
application's performance than leaks caused by developers."
在这一点上我可以看到它与“大岛”理论之间的联系 - 假设理论是正确的,我不是。在这一点上,Adobe至少在第二个声明中承认,至少有一些良性问题可以被孤立的孤儿。他们表现得并不是什么大不了的事情,但是就这样离开它并假装没什么可能只是典型的Adobe邋。。如果他们提到的那些罕见的错过的孤儿之一在其中有一个大的,完全活跃的对象层次结构怎么办?如果你无法完全阻止内存泄漏那么我肯定会看到如何通过并执行诸如在丢失引用之前将整个层次结构中的引用归零的操作通常会做很多事情以最大限度地减少因泄漏而导致的内存量
我的想法是,垃圾收集器通常仍然能够摆脱岛内的大部分内容,而不是岛屿本身。还有一些被认为能够真正使用“大岛”理论的人看到的可能是Adobe承认的一些“不那么良性”的表现形式。这仍然是一个假设。
编辑:在我再次检查了析构函数并理顺了几个问题之后,我确实看到了一个显着的改进。我正在离开这个问题的原因是,我不仅有机会遗漏我可以做的其他事情以释放记忆,但到目前为止我使用的主要解释并非官方或经证实答案 0 :(得分:0)
尝试致电
try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.
强制垃圾收集。这是没有记载的,但是对于格兰特斯金纳来说是有用的,他在blog
上解释了更多