Question

我一直在努力追踪我们的应用程序中的内存泄漏，并继续发现自己回想起Spark组件是罪魁祸首。

我想我找到了原因，但我对Garbage Collection / mark＆amp; amp;扫描不是太热，所以我想验证我的发现。

Spark中的许多类使用RichEditableText来显示其文本属性（ComboBox，TextInput）。

RichEditableText有一个本地textContainerManager媒体资源，经常就此调用compose()。

以下是来自TextContainerManager

的相关精简摘录

// Line 282 - 292:
    static private var stringFactoryDictionary:Dictionary = new Dictionary(true);
    static private function inputManagerStringFactory(config:IConfiguration):StringTextLineFactory
    {
        var factory:StringTextLineFactory = stringFactoryDictionary[config];
        if (factory == null)
        {
            factory = new StringTextLineFactory(config);
            stringFactoryDictionary[config] = factory;
        }
        return factory;
    }
// Line 1204:
public function compose() {
    // Line 1238:
    var inputManagerFactory:TextLineFactoryBase = (_sourceState == SOURCE_STRING) ? inputManagerStringFactory(_config) : _inputManagerTextFlowFactory;
    // Line 1242:
    inputManagerFactory.swfContext = Configuration.playerEnablesArgoFeatures ? this : _swfContext;
}

第1242行是关键行，因为它为静态字典提供了对我们组件的引用。

（注意 - 我已经使用调试器检查了这一点，以确认三元的哪个分支被执行。）这样可以防止实例被垃圾回收。

例如：静态字典的值带有对实例的引用 - 实例不能是GC'd。

反过来，这也会阻止任何其他引用TextContainerManager实例的实例也被GC。

虽然这个理论肯定与我在应用程序中看到的理论相符，但我无法相信在这样的低级别火花组件中确实存在内存泄漏。

有人可以对此有所了解吗？

BTW - 我在bugs.adobe.com上打开了一个缺陷来跟踪这个问题，如果它被证明是一个真正的错误： https://bugs.adobe.com/jira/browse/SDK-29531

Answer 1

我听说有几个与TLF相关的内存问题。这应该在Flex 4.5 SDK中得到纠正。

与此同时，你仍然可以在http://bugs.adobe.com/jira/

上开票

火花内存泄漏

1 个答案: