Analysis and diagnosis of flex application memory leak

Introduction

Flex uses the ActionScript language as the scripting language, and the compiled binaries run in the Flashplayer virtual machine AVM (ActionScript virtual Machine). Like the Java language, there is also a garbage collector (garbage Collection) in the AVM that collects and destroys the unused objects over time, freeing up memory. Compared to the C + + language, programmers do not need to focus on memory allocation and release at all times, greatly reducing the burden. But the garbage collector does not fundamentally address the problem of Flex memory leaks, as it does from the garbage collection mechanism of flashplayer virtual machines.

Garbage collection mechanism of flashplayer virtual machine

The garbage collector uses a notation or notation to find the objects that need to be purged. The Count method is now rarely used because it cannot detect the objects that are circular references. Focus on the labeling method. The objects that Flex applies are mapped in memory into a tree structure. It is well understood that each Flex application has a application portal called the root node, the garbage collector traverses each object from the root node, marking the accessible object as "valid" (with one exception being a weak reference, followed by a detailed chapter). An island object outside this tree or a collection of islands objects formed by circular references is marked as "invalid", and the garbage collector destroys these invalid objects at the right time and completes a garbage collection. The garbage collector is a low priority daemon running in a virtual machine, and it runs only when necessary, in order not to affect performance. For example, when a new memory space is applied to the operating system, when an exception occurs, and so on, the memory is not recycled in real time.

Reasons for Flex memory leaks

With the garbage collector, why does Flex also generate memory leaks? From the point of view of the garbage collector, the objects are divided into "valid" and "invalid" categories, and from the perspective of the Flex application, the objects are divided into "useful" and "useless".

For example, when a program has a logical error that requires prompting the user, the Flex program constructs a prompt box, at which point the prompt box is a "useful" object, and when the user clicks the Close button to turn off the cue box, the prompt box becomes a "useless" object and the application never uses it again (the next time the same logic error occurs, the program A new balloon is also constructed. The application thinks the cue box should be recycled, but for some reason there is a reference from the "valid" object to the Prompt box, and the garbage collector apparently thinks the prompt box is also "valid." This "valid" "useless" cue box causes Flex memory leaks.

Two scenarios in which memory leaks are caused during development

Understanding the reasons for flex memory leaks, from a programmer's point of view, confusing management of object references is an artificial factor that causes flex memory leaks. There are two types of references to objects in FLEX development: Display references and implicit references, and we discuss how they can cause memory leaks in each of these two situations.

Show references

The expression B=a, creates a reference from B to a, and when a becomes a useless object, A's memory cannot be reclaimed because B has a reference to it. In the development process, global variables, static variables, especially those created in a single case pattern, references to other objects, if not released in time, can easily lead to memory leaks. For example:

Listing 1. Expression Display Reference

public　static　var　staticVar　:　Object　=　new　Object();
　 public　function　leak():void{
　var　chart　:　AreaChart　=　new　 AreaChart();
　staticVar　=　chart;
　chart　=　null;
　}

In the leak () method, a temporary variable chart is created and then assigned to the static variable Staticvar, although the chart is finally set to NULL, but because the static variable has a reference to it, the memory of the chart is not recycled, causing memory leaks.

A method that takes an object as a parameter creates a reference to the object within the method body that is not released in time and results in a memory leak. Change the code above:

Listing 2. Method with Object as parameter

var　chart　:　AreaChart　=　new　AreaChart();
　leak(chart);
　chart　=　null;
　......
　public　static　var 　staticVar　:　Object　=　new　Object();
　public　function　leak(chart　: 　AreaChart):void{
　staticVar　=　chart;
　}

The reason is the same as the previous example, but the position is more covert.