Java profiling tool JProfiler getting started Tutorial: Find memory leaks

JProfilerThe memory View session provides a dynamic update view of memory usage and an Information view of the allocation point. All views have several clustering layers and can display existing objects and objects as garbage collection objects. This article describes how to realizeMemory leakageAnd several methods to find memory leaks.

Aware of Memory leakage

The first step to suspect Memory leakage is to view the "Memory" and "Recorded objects" remote sensing survey views. When the application memory leaks, the view displays a linear positive trend with a shock. Without such a linear trend, your application may only consume a large amount of memory, rather than memory leakage. The solution is simple. Find out the classes or arrays that occupy a large amount of memory and minimize the number of classes or arrays.

Memory leakage reduced by usage difference

The first step to find out the origin of Memory leakage is to find the difference between the object view and the recorded object view. Simple Memory leakage can be traced using the differential function.

Observe the differences between the object view and the recorded object view, and find out which classes are caused by the difference. Then, when switching to the hotspot view, select the problem category and observe the differential columns assigned by the problem instance. In this case, you know how to create an instance.

Heap traversal and Memory leakage

When obtaining a bunch of snapshots, you must first create an object set with an object instance. If you have narrowed the cause of Memory leakage in the dynamic memory view, you can use "show selection in heap walker" to save the operation and start the heap traversal.

Use the object view to find out the cause of Memory leakage

Most memory leaks can be traced back to the object cluster. This will generate some large retained size objects. The largest object view lists objects with the maximum retained size. You can use this tree to drill down to find the wrong reference.

Use the reference diagram to find out the cause of Memory leakage

The core tool used to identify memory leaks is the reference diagram in the heap traversal tool. Open the incoming reference in turn, and you may immediately find an incorrect reference. In complex systems, this is often impossible. In this case, you must find one or more "garbage collector roots ". Garbage collector roots is a node in JVM and is not subject to the Garbage collection mechanism. The [Show path to GC root] button on the top is enabled when you select to pass in a reference or an object in the image.

There are a lot of garbage collector roots. If all of them are displayed, it may cause a lot of accumulation ,. It is also time consuming to search for garbage collector roots. If tens of thousands of roots are found, the calculation takes a long time and takes a lot of memory. To prevent these problems, it is best to start from a single garbage collector root, and then add garbage collector root as needed based on the use of UP to roots.

The chain of garbage collector root can be very long ,:

Use cumulated references views to find out the cause of Memory leakage

In some cases, you may not be able to successfully scale down the object settings. Your object set may still contain a large number of instances or in this case, you cannot provide any insights using the reference diagram. In this case, the cumulated reference tables in the reference view of the heap traversal server can be used. Cumulated incoming reference table shows all possible reference types in the current object set:

From the reference type, you can narrow down the object set. For example, you may know that the reference types are normal and those are not.