Methods for identifying leaked objects

In general, the memory usage of a normal system is basically stable after it runs stably, and should not increase without limit. Similarly, there is also a relatively stable upper limit on the number of objects used for any class, and it should not continue to grow. Based on this basic assumption, we can continuously observe the memory size used during system operation and the number of instances. If the memory size continues to grow, it indicates that the system has memory leakage, if the number of instances of a class continues to grow, it indicates that the instance of this class may be leaked.

Optimizeit is a Borland product mainly used to assist with software systems.CodeIt has many functions and is easy to use. optimizeit profiler is mainly used for Memory leakage analysis. The heap view of profiler (4) is used to observe the memory size used by the system operation and the number of instances allocated for each class, as shown in interface 4, the column names from left to right are the class names, the number of current instances, the number of instances that have increased since the previous tag point, the size of memory space occupied, and the number of instances that have increased since the last tag point. memory size, number of released instances, memory size that has increased since the last mark point, number of released instances, the last row of the table is the summary data, indicating the total number of object instances in the current JVM, the total number of instance growth, the total number of memory usage, and the total number of memory usage increases.

In practice, the system can run for four hours, eight hours, twelve hours, and twenty-four hours to record the memory status at that time (that is, capture the memory snapshot at that time, is the function provided by the tool, and this snapshot is also used for further analysis), find the top 10 classes with increasing number of instances, and record the names of these 10 classes and the number of current instances. After the data is recorded, click the mark button in the upper-right corner of profiler to compare the status of the point to the next data record.

Figure 4 profiler heap View

After the system runs 24 hours, you can get four memory snapshots. Perform a comprehensive analysis on the four memory snapshots. If the memory usage of Each snapshot is higher than the previous one, you can determine that the system has memory leakage, find out the classes that keep the number of instances increasing in the four snapshots. These classes can be initially identified as leaked.

Analysis and positioning

Through the above data collection and preliminary analysis, we can draw a preliminary conclusion: whether the system has memory leakage and which objects have been leaked (leaked). If the conclusion is that there is a leakage, you can enter the analysis and positioning phase.

As mentioned above, memory leakage in Java is an unconscious Object persistence, simply put, a reference chain that should not have existed due to an Encoding Error (as a result, the referenced object cannot be released ), therefore, the task of Memory Leak analysis is to find out the redundant reference chain and find the cause of its formation. We have also talked about channeling objects, including static variables of loaded classes and variables in the stack space of active threads. Because the stack space of the active thread changes rapidly, the traction object set in the stack space changes rapidly, the collection of traction objects as static variables of the class is relatively stable during system operation.

For each leaked instance object, there must be a reference chain to reach the object starting from a traction object. When the pull object in the stack space is popped up from the stack, it will lose its traction capability and become a non-traction object. Therefore, after a long period of operation, the leaked objects are basically pulled by the static variables of the class.

In addition to the heap view, the profiler memory view also includes the instance allocation view (figure 5) and instance reference diagram (figure 6 ).

The instance reference diagram of profiler provides a very direct method to find the reference chain from the traction object to the leaked object, the second column of the interface shows the reverse reference chain starting from the leaked object. It should be noted that when a class instance leaks, not all of its instances are leaked, and only some of them are leaked objects, while others are normal objects, determine which are normal reference chains and which are abnormal reference chains (the leaked reference chains ). After extracting multiple instances for reference graph analysis and statistics, you can find one or more reference chains starting from the traction object. The following task is to find out the reason for the formation of this reference chain.

The instance distribution graph provides the function of collecting statistics on the allocation locations of instances of each class. Viewing the statistical results of instance allocation has a certain effect on analyzing the formation of the reference chain, the reason for the formation of the reference chain is often found at the intersection of the allocation chain and the reference chain.

Figure 5 instance distribution chart

Figure 6 instance reference

Suppose that an Instance Object A is allocated in method F and eventually referenced by instance object B. The following analyzes the possible causes of the formation of the reference chain from B to. Method F divides the use of object a into four situations: 1. Return A as the return value; 2. Call other methods using a as the parameter; 3. Pass the reference of a to other objects within the method; 4. Other cases. Case 4 does not generate a reference chain from B to. The following three cases are considered: for the first and second cases, the result is that the reference of object A is obtained within the other method, its analysis is exactly the same as that of method F (recursive analysis). Consider 3rd cases: 1. Assume that method F directly adds the reference of object A to object B, then, the reference chain from object B to object A is found and the analysis is complete. 2. Assume that method F adds the reference of object A to object C, then we need to track the use of Object C, object C has more analysis steps than object A, but the general principle is the same, that is, tracking the process of objects used after creation, finally, find the reason why it is referenced by the traction object.

Now we have found the cause of the reference chain of the leaked object and the formation of the reference chain, and the memory leakage testing and analysis work has ended, the next step is to modify the design or implementation errors.