. Memory leak analysis and diagnostics for NET managed memory class applications

In managed memory management, the "leak" meaning differs from the forgotten explicit release (delete/delete[] in traditional Native applications), and it is necessary, of course, for unmanaged resources such as handles, or in the Finalize (the destructor is equivalent to Finalize) method, which is explicitly disposed in the the "Leak" object instance in managed memory management refers to the fact that the GC thread is not allowed to be freed, even though it is no longer used, because there is a referential relationship that should have been disconnected from the object in the Root object set. In most cases, because the application (the programmer) thinks that the object will not exist, and when it is reused, and then creates the object instance again in the managed heap, it can be imagined that the consequences are serious and that the heap memory will be full as the number of creation increases. (The G3 zone in the managed heap is full and the G2 area cannot make room).

The GC determines whether an object can be freed by traversing all the objects and child objects referenced by it, starting with the root object, such as the args parameter of the Main function, the static variable, and its object members. GC executes by marking objects in these references, clearing unmarked objects to complete memory release (tagging, Cleanup algorithms), and, of course, purging may be step-by-step (such as transferring Finalize queues, etc.). Due to performance considerations such as marking, the interrupt time of the cleanup algorithm, the managed heap partition (generation), the current CLR is 3 generation –g1, G2, G3. With age (GC 1) increases, the object will gradually transfer from G1 to G3 generation (copy, collation algorithm), that is, G1 is the Cenozoic, are some short-term objects, G3 is the permanent residence of the elderly object. It is necessary to note that there are actually 2 managed heaps (SOH and LOH) in the current version of the. NET CLR, one of which is called the large object managed heap (LOH), which is designed to store objects larger than the 999 Bytes. Programs can allocate object space only in SOH G1 and LOH, and only CLR GC threads can allocate (transfer) objects in SOH G2, G3.

To understand the basics above, take a look at the legend of the memory leak in the managed object instance:

The meaning shown in the above figure is that after a period of time, the object in the heap is referenced to the Root object, where the color from shallow to deep indicates the age factor. If the GC thread is executing at this point, the heap situation will look like the following:

All of these unreachable object instances are freed by GC so that the managed heap memory is properly reclaimed. However, it is necessary to note that if you are in a reachable area where the GC is not released, there are some referenced objects that will not be used later, and "leaks" occur when the application (the programmer) creates a new object in the next use. When the business involved in creating an action on such an object is repeatedly executed by the user, the G3 generation of the CLR is gradually growing, and the service will not die far.