Silverlight Memory leakage (2) detection of Memory leakage

Understand GC

It is easy to understand many strange problems in. net Programs If GC works. Although. net has always claimed.. net programs do not require explicit memory management. GC releases unwanted objects in the background, and developers do not need to manage objects. net programs still need to pay attention to memory leakage and performance issues. In particular, Silverlight and WPF have more serious memory leakage than other. net programs.

GC solves memory leaks that often occur in unmanaged programs. For example, developers forget to release their own resources. Since GC can release the memory, why is there Memory leakage? There is only one reason. GC and developers have different understandings about whether the object is "live" and whether it is being used. Developers think that the object is useless and can be recycled by GC, but GC thinks that the object is being used and the memory will not be recycled. Therefore, you must understand the GC mechanism.

GC is briefly introduced below. For more information, see other materials.

1. Large and small objects

Objects larger than 85k or multi-dimensional arrays greater than 8 k will be allocated to the LOH heap.

Other objects are small objects.

2. GCroot

To put it simply: GC releases the memory starting from the Root, as long as the objects that can be reached by the Root are considered live and will not be recycled.

GCroot is not an object. Any object referenced by GCroot can automatically survive in the next GC. There are four types of GCRoot:

A) the local variable in the method is considered as root during the method execution period.

B) static variables are always considered as Root: thread static will not be recycled during the life cycle of the thread, and Other types will continue until the end of the program.

C) The managed object is passed to the unmanaged code, and the managed object is considered as ROOt.

D) The finalizer object is implemented. After GC, although GC considers that the object is no longer alive, such objects are also considered as ROOT before finalizer is executed. Therefore, if you check that the finalizer object still exists, it is not necessarily a memory leak. The next GC will be recycled.

3. object graph

The relationships between objects in the memory constitute an object graph. An object may have multiple paths from root to this object. to release this object, all references must be dropped.

: ClassC has three paths: root1-> ClassC, root2-> ClassC, root3-> Class

B-> ClassC.

To release ClassC memory, you must cut off three paths.

It can be seen that memory leakage is usually caused by the developer forgetting or failing to realize that an object may have multiple roots.

4. GC generation

5. LOH large object heap

Objects larger than 85k or multi-dimensional arrays greater than 8 k will be allocated to LOH, large objects will not be compressed, and fragments will be easily formed, and an OutOfMemoryException will be thrown, large objects are only executed when full recovery is executed, that is, when Gen2 is executed. Memory issues generated by large objects are not discussed.

Detect memory leakage

Many tools can detect Memory leaks, and now use the ANTS Memory Profiler tool.

Use help: http://www.red-gate.com/supportcenter/Content? P = ANTS % 20 Memory % 20 Profiler & c = ANTS_Memory_Profiler/help/7.0/amp_getting_started.htm & toc = ANTS_Memory_Profiler/help/7.0/toc.htm.

Steps for detecting memory leaks

1. Understand your code and where it is prone to memory leakage.

For Silverlight, you can pay attention to the UI. The reader program detected this time adopts the MVVM architecture, which may cause leakage. The MVVM structure is shown below:

We can see that the most common cause of Memory leakage is View.

2. Open ANTS Memory Profiler, New Profile Session

Uri: html or xap address. If it is an OOB program, you must ensure that OOB is not installed locally. Otherwise, the following information is displayed:

3. Steps for detecting leaks using ANTS

A) perform several redirection operations to obtain the memory snapshot.

B) Search for the View in the Class List View

You can see that the View instance is 2 and should be 1.

C) view the Instance category in the Instance Cataegorizer view. ANTS classifies all Instace from GCRoot to the current object based on the path. Here you can have a basic understanding of the Instance Live situation.

Two categories are displayed. The first one may be Memory leakage.

D) In the Instance List View, re-execute operations that may cause memory leakage and obtain snapshots again, for example:

You can see that the first instance is the object that was not recycled by the last GC.

In addition to estimation of Memory leakage Objects Based on code, leakage objects are generally far away from GC, and the larger Gen is, the more likely it is to leak objects.

E) The Instance Retention Graph view displays all paths from Root to the current object. To solve the memory leakage problem, start from here.

By comparing the two figures, we can find the possible leak. The main focus is on the object graph that was not recycled last time.

Note: you do not need to take a look at the details of the Instance Retention Graph view.

The object is stored in the cache.

Tips

1. the GC collection time is not controllable. You can add the GC collection code:

GC. Collect ();

GC. WaitForPendingFinalizers (); // because it is a Finalize object, it will still exist as root after the first GC, and the memory will be released at the next GC.

GC. Collect (); // ensure that the Finalize object is released

2. Perform Two snapshot operations