Memory leak troubleshooting from entry to mastery

The most primitive memory leak test

Repeat the operation of the key suspicious path many times, and observe the memory curve from the memory monitoring tool to see if there is a rising trend and no obvious drop when the program returns. This method can find the most basic and obvious memory leak problem, which is of great value to users, easy to operate, and highly cost-effective.

MAT memory analysis tool

2.1 MAT analyzes the total memory usage of the heap to preliminarily determine whether there is a leak

In Devices, click the program you want to monitor.

Click "Update Heap" in the top row of icons in the Devices view interface

Click the Heap view

Click the "Cause GC" button in the Heap view

At this point the process to be detected can be monitored.

In the middle of the Heap view, there is a Type called data object, which is a class type object that exists in large numbers in our program. In the data object row, there is a column called "Total Size", whose value is the total memory of all Java data objects in the current process. Generally, the size of this value determines whether there will be a memory leak. You can judge it like this:

Enter an application, operate it continuously, and pay attention to the Total Size value of the data object. Under normal circumstances, the Total Size value will be stable within a limited range, which means that the object is not garbage collected because the code in the program is good.

So although we keep operating and generating many objects, these objects are recycled during the GC process of the virtual machine, and the memory usage will fall to a stable level; on the contrary, if there is no release of object references in the code, the Total Size value of the data object will not drop significantly after each GC. As the number of operations increases, the Total Size value will increase until it reaches an upper limit, causing the process to be killed.

2.2 MAT analyzes hprof to locate the cause of memory leaks.

This is an effective way to use MAT to locate the problem after a memory leak occurs.

A) Dump the memory image hprof at the time of the memory leak and analyze the suspected leaked class:

B) Analyze external objects that hold references to such objects

C) Analyze the GC paths of these objects holding references

D) Analyze the GC path of each object one by one to see if it is normal

From this path, we can see that an antiRadiationUtil tool class object holds a reference to MainActivity, which causes MainActivity to be unable to be released. At this point, we need to enter the code to analyze whether the reference holding of antiRadiationUtil is reasonable (if antiRadiationUtil holds the context of MainActivity, causing MainActivity to be unable to be destroyed after the program exits, it is generally a memory leak).

2.3 MAT compares hprof before and after the operation to locate the root cause of the memory leak.

To find memory leaks, you usually need to compare two dump results. Open the Navigator History panel and add the Histogram results of the two tables to the Compare Basket.

A) First HPROF file (using File > Open Heap Dump ).

B) Open Histogram view.

C) In the NavigationHistory view (if you can't see it, go to Window > show view > MAT- Navigation History), right-click on the histogram and select Add to Compare Basket.

D) Open the second HPROF file and redo steps 2 and 3.

E) Switch to the Compare Basket view, and then click Compare the Results (the red "!" icon in the upper right corner of the view).

F) Analyze and compare the results

The comparison results of the two hprof data objects can be seen. In this way, the increment of objects held before and after the operation can be quickly located, so as to further locate the specific cause of the memory leak caused by the current operation and what data object is leaked.

Notice:

If the dump file is obtained using the MAT Eclipse plug-in, it can be opened in MAT without conversion, and Adt will automatically convert it.

The files dumped by the mobile phone SDk need to be converted before they can be recognized by MAT. Android SDK provides this tool hprof-conv (located in sdk/tools)

First, go to your android sdk tools directory through the console and execute the following command: ./hprof-conv xxx-a.hprof xxx-b.hprof For example, hprof-conv input.hprof out.hprof Only then can you open out.hprof in eclipse's MAT.

Mobile Manager Memory Leak Daily Monitoring Solution

Currently, the daily memory leak monitoring of the mobile phone manager will automatically run and output a report email if there is a suspected leak, regardless of the size of the leaked object. The core technologies involved are mainly AspectJ, MLD self-developed tools (the principle is virtual reference) and UIAutomator.

3.1 AspectJ instrumentation monitoring code

Mobile Manager currently uses an ant script to add MLD monitoring code and implements the instrumentation through AspectJ syntax. The reason for using AspectJ is that it can flexibly separate the project source code and the monitoring code, and package installation test packages for different purposes through different compilation scripts: If the test package is instrumented with MLD monitoring code through Aspect, then after running, a log file in a specified format will be output as the data basis for subsequent analysis work.

3.2 MLD implements monitoring core logic

This is a tool project in the mobile phone manager. It will not be included in the official package, but can be included in the daily monitoring test package such as BVT. After being included, you can add the detection object to be monitored through interfaces such as addObject (check whether the tool is included and call it through reflection). This tool will automatically detect whether the object has leaks at the specified time (such as exiting the manager).

The basic principle of this memory leak detection is:

Phantom references are mainly used to track the activities of objects being collected by the garbage collector. Phantom references must be used in conjunction with the reference queue (ReferenceQueue) (they must be associated and specified in the phantom reference function). When the garbage collector is ready to recycle an object, if it finds that it still has a phantom reference, it will automatically add this phantom reference to the reference queue associated with it before reclaiming the object's memory. The program can determine whether the referenced object is about to be garbage collected by determining whether a phantom reference has been added to the reference queue.

Based on the above principle, when the MLD tool calls the addObject interface to add a monitoring type, it will add a virtual reference to the object of that type. Note that the virtual reference does not affect the normal recycling of the object. Therefore, you can count whether the number of unrecycled monitoring objects exceeds the specified threshold in the ReferenceQueue reference queue.

Using PhantomReferences and ReferenceQueue, when PhantomReferences is added to the associated ReferenceQueue, the object is considered to have been or is in the garbage collector recovery phase.

MLD monitoring principle core

Currently, Mobile Manager has completed memory leak monitoring for most classes, including various activities, services, and view pages, in order to provide users with the smoothest product experience in terms of technology.

Next, I will briefly introduce the core of this tool. Based on the memory status monitored by virtual references, multiple strategies are needed to determine whether there is a memory leak.

(1) The simplest way is to set the maximum number of instances of the type when adding monitoring. For example, each DAO object can theoretically only exist once, so if two identical DAOs appear, it is generally a leak.

(2) The second situation is that when the page exits the program, the list of objects that cannot be released after GC is retrieved. These object types will also become suspected objects of memory leaks;

(3) The first case is more complicated. The basic principle is to determine the growth rate of the number of objects based on historical operations. The growth rate of the object type is fitted using the least squares method based on the growth of the object. If it exceeds the empirical value, it will be included in the list of suspected leaked objects.

3.3 UIAutomator completes automation of repetitive operations

***One step is very simple. It is a waste of manpower to let people do so many repeated UI operations manually. We use UIAutomator to perform automated operation tests.

Currently, the daily automated testing of Mobile Manager has covered the main paths of each function, and flexibly drives the addition, deletion, modification and query of use cases through configuration files, thus ensuring the reuse value of use cases to the greatest extent possible as versions change.

This concludes the introduction to the memory leak testing solution for Mobile Manager. Welcome experts from all walks of life to communicate and exchange more powerful memory leak toolbox solutions!

Introduction to Tencent Bugly

Bugly is an external version of Tencent's internal product quality monitoring platform. Its main function is to monitor and report crashes and freezes that occur on the user side after the App is released, so that developers can understand the quality of the App in real time and make timely model modifications. Currently, all Tencent's internal products are using it to monitor online product crashes.