Adobe Flex - Memory Leak

Flash Player Garbage Collection

Garbage collection is a process that reclaims memory no longer in use so that it can either be reused by the application or, in some cases, given back to the operating system. Garbage collection happens automatically at allocation, which is often confusing to new developers. This means that garbage collection does not occur when memory is no longer in use, but rather occurs when your application asks for more memory. At that point, the process responsible for garbage collection, called the Garbage Collector, attempts to reclaim available memory for reallocation.

The Garbage Collector follows a two-part procedure to determine which portions of memory are no longer in use. Understanding this procedure will give you the insight necessary to develop applications that use memory appropriately and to understand the information presented by the Flex profiler.

The first part of the garbage collection procedure is referred to as reference counting, and the second is referred to as mark and sweep. Both rely upon different methods of ensuring that the memory in question is no longer referenced by other objects in use.

Understanding leaks caused by event listeners

Objects that wish to be notified when an event occurs register themselves as listeners. They do this by calling the addEventListener() method on the object that broadcasts the event (called the broadcaster or dispatcher).

The following example shows a simple case:

var textInput:TextInput 

= new TextInput(); 

textInput.addEventListener

(‘change’, handleTextChanged);

In this case, the TextInput is expected to broadcast an event named change at some point in the future, and you want the handleTextChanged method to be called when this occurs. When you call addEventListener() on the TextInput instance, it responds by adding a reference to the object (the one that contains the handleTextChanged method) to a list of objects that need to be notified when this event occurs. When it is time to broadcast the change event, the TextInput instance loops through this list and notifies each object that registered as a listener.

The important thing is that each object that broadcasts an event maintains a reference to every object listening for the event to be broadcast. In terms of garbage collection this means that, in certain circumstances, if an object is listening for events, it may never be available for garbage collection.
Note: For more information on event dispatching, please refer to the IEventDispatcher interface in the Flex 3 livedocs.

Your main weapon to combat this problem is diligence. Much like any child that is added with addChild() can be removed with removeChild(), addEventListener() has a parallel function named removeEventListener() that stops listening for an event. When removeEventListener() is called, it also removes the reference to the listener kept by the broadcaster, potentially freeing up the listener for garbage collection.

In an ideal world, the number of addEventListener() and removeEventListener() calls in your application should be equal. However, there are times when you have less control over when objects are no longer needed and using removeEventListener() is simply not feasible. In these situations, we can use a concept called weak references.

Using weak references with listeners

When adding an event listener to a broadcaster, the developer can specify that the event listener should use weak references. This is accomplished by specifying extra parameters to the addEventListener() method.

var textInput:TextInput 
= new TextInput(); 
textInput.addEventListener
(‘change’, handleTextChanged
, false, 0, true);
Previously, we used the first two parameters of the addEventListener() method: the name of the event and the method to call when the event occurs. However, there are three other parameters that can be specified. In order, these parameters specify whether the event listener should use capture, its priority relative to other listeners for this event, and finally whether weak references should be used. The first two are beyond the scope of this topic, but the last one is critical to garbage collection.

addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void

Specifying a value of true (the default is false) for the fifth parameter of the addEventListener() method specifies that the reference established by this listener is to be considered weak. All the other references are considered strong references

As a more concrete example, if an object had a strong reference and three weak references to it, it could not be collected as garbage. However, if the strong reference was removed, the weak references would be ignored and the object could be collected.
In practice, this means that specifying the weak reference flag on addEventListener() calls is almost always a good practice. It prevents the case where listening to an event is the only reason that an object is not collected.
The other place that weak references are supported is in the Dictionary object. Simply pass true as the first parameter when you instantiate a new Dictionary to have it use weak references as its keys:
var dict:Dictionary = new Dictionary(true); dict[myObj] = myOtherObj;
 // the reference to myObj is weak, the reference to myOtherObj is strong
Richard Lord over at Big Room Games has an interesting article on hacking AS3 to allow you to create weak-references to objects. 
Using the WeakReference hack could be useful if you want to make sure that an object will not stay in memory if you forget to delete all references to it. However, keeping track of your objects and practicing good memory management is a much better solution and hacks like this one should be saved for special cases where tracking use of an object becomes difficult or impractical.
Further Reference: click here