1

我开始遇到严重的问题，垃圾收集器部分处理了这个问题，但仍然让大部分对象在没有引用的情况下在后台启动并运行：

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 的空间未被收集。

如何解决这个问题？谢谢！

编辑：鉴于 Adob​​e 在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 在这一点上几乎承认，至少在第二个声明中，至少存在与孤儿被跳过的良性问题。他们表现得好像没什么大不了的，但是就这样离开它并假装什么都不是，这可能只是典型的 Adob​​e 邋遢。如果他们提到的那些罕见的遗漏孤儿之一在其中有一个大的、完全活动的对象层次结构怎么办？如果您不能完全防止那里的内存泄漏，我绝对可以看到在丢失引用之前如何通过和执行诸如在整个层次结构中清空引用之类的事情通常会做很多事情来最大程度地减少内存泄漏量.

我的想法是垃圾收集器通常仍然能够清除该岛内的大部分东西，而不是该岛本身。此外，其中一些据称能够真正使用“大岛”理论的人所看到的可能是 Adob​​e 所承认的一些“不太良性”的表现。不过，这仍然是一个假设。

编辑：在我再次检查析构函数并解决了几个问题后，我确实看到了显着的改进。我留下这个问题并继续下去的原因是，不仅有机会我仍然错过了我可以做的其他事情来释放内存，而且我到目前为止使用的主要解释不是官方的或经过验证的.

4

1 回答 1

0

试着打电话

try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.

强制垃圾收集。这是无证的，但有效.. 归功于 Grant Skinner，他在他的博客上解释了更多

于 2013-01-09T15:43:37.713 回答