火花内存泄漏 [英] Spark memory leaks

问题描述

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

我想我已经找到原因，但我对垃圾收集/标记&扫描是不是太热，所以我想验证我的发现。

在Spark中的许多类使用 RichEditableText 用于显示文本属性（ ComboBox ， TextInput ）。
$ b

RichEditableText 有一个本地的 textContainerManager 属性，在这里调用 compose（）。

以下是从 TextContainerManager < code

$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $真正）;
静态私有函数inputManagerStringFactory（config：IConfiguration）：StringTextLineFactory
{
var factory：StringTextLineFactory = stringFactoryDictionary [config];
if（factory == null）
{
factory = new StringTextLineFactory（config）;
stringFactoryDictionary [config] = factory;
}
返回工厂;

//行1204：
public function compose（）{
// Line 1238：
var inputManagerFactory：TextLineFactoryBase =（_sourceState == SOURCE_STRING）？ inputManagerStringFactory（_config）：_inputManagerTextFlowFactory;
//第1242行：
inputManagerFactory.swfContext = Configuration.playerEnablesArgoFeatures？这个：_swfContext;





$ b

1242行是关键的一行，因为它给静态字典一个参考到我们的组件。



（注意 - 我已经用调试器检查了这个以确认三元组的哪个分支被执行）。这将防止实例被垃圾集。

$ b

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

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

尽管这个理论与我在应用程序中看到的一致，但是我不能相信在这样一个低级别的spark组件中真的存在内存泄漏。

请问有人可以对此有所了解？

顺便说一句 - 我已经在bugs.adobe.com上打开了一个缺陷来跟踪这个问题，证明是一个真正的bug：
https://bugs.adobe.com/ jira / browse / SDK-29531

解决方案

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

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

I've been trying to track down memory leaks in our application, and keep finding myself back looking at Spark components as the culprit.

I think I've found the cause, but my understanding of Garbage Collection / mark & sweep is not too hot, so I'd like to verify my findings.

Many classes in Spark use RichEditableText for displaying their text properties (ComboBox,TextInput).

RichEditableText has a local textContainerManager property, and frequently calls compose() on this.

Here's the relevant abridged extract from 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;
}

Line 1242 is the crucial line here, as it gives the static dictionary a reference to our component.

(Note - I've checked this with the debugger to confirm which branch of the ternary gets executed.) This would prevent the instance from ever being garbage collected.

Eg: Static dictionary has a value with a reference to the instance -- instance cannot be GC'd.

In turn, this would prevent any other instances which have a reference to the instance of TextContainerManager from being GC'd also.

While this theory certainly matches what I'm seeing in our app, I can't beleive that there really is a memory leak in such a low-level spark component.

Could someone please shed some light on this?

BTW - I've opened a defect on bugs.adobe.com to track this issue, should it prove to be a genuine bug: https://bugs.adobe.com/jira/browse/SDK-29531

解决方案

I've heard there are several memory problems related to TLF. That should be corrected in the Flex 4.5 SDK.

In the meantime, you could still open a ticket on http://bugs.adobe.com/jira/

这篇关于火花内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！