Use jprofiler for memory Analysis

In recent work, jprofiler is used to solve the memory leakage problem. Now we have recorded the detection steps and some analysis results, and we can use them as a reference when we encounter similar problems in the future.

 

Running Environment: tomcat6, jdk6, jprofiler8

 

Memory leakage: 1. when performing some batch operations on the server, it is found that the memory only rises or falls; even after GC, the memory cannot be completely released; 2. unless the Tomcat server is restarted, the memory will never be released. Repeated operations will result in no available memory and Tomcat will die;

 

To check for Memory leakage using jprofiler: 1. initialize the check environment:

Switch to the "live memory --> all objects" tab to view the objects in current tomcat. Note that other jprofiler versions may have different locations.

Before performing the operation, run "run GC" on F4. this allows JVM to recycle and clear invalid objects. to facilitate memory growth, right-click ---> "Mark current ",

The current memory usage is used as a reference. Click it to display the "difference" column, which lists the change and change ratio of the number of objects.

2. Enable the memory record:

Click Start recordings to start recording. The main purpose of this step is to set a monitoring interval for the following "heap Walker". If no record is made, "heap Walker" will analyze all the memory of the JVM virtual machine, that is, the cause of Memory leakage is time-consuming and inaccurate.

3. execute the operation and perform GC. Use the stress tool to access the tested application and then run F4 again to perform GC-this is to eliminate the items that can be recycled. After the memory is recycled, objects still in the memory may be leaked. If the red department in instance count is an object that cannot be recycled, the difference column lists the number of added objects and the increase. Taking string as an example, an increase of 31751 objects is increased to 14% in this operation. Then, the heapwalker observes these objects and analyzes which objects are leaked. Objects that cause leakage include string, char [], hashmap, concurrenthashmap, etc. These objects need to be focused. 4. disable memory record: click "Stop recordings" to close the memory record and tell jprofiler to use this record as the analysis object; 5. find the rapidly increasing object type and open heapwalker:

Find the fast-growing object type in the view. In this example, concurrenthashmap is growing fast. In the memory view, find concurrenthashmap --- Right click ---- select "show selectiion in heap Walker" and switch to the heapwarker view. The option page is displayed before switching. Be sure to select "select recorded objects ", in this way, heap Walker will analyze in the previous record; otherwise, it will analyze all the memory objects of Tomcat, which is time-consuming and inaccurate;

6. Find the leaked object in heapwalker. heapwarker analyzes all objects in the memory, including the reference, creation, size, and quantity of the object. You can switch the page below the heapwarker View:

Switch to the references tab to view the object instance of this class.

To find the leaked object (which should be recycled) Among these memory objects, right-click the object and select "Use selected instances" to narrow down the object range;

Click OK

7. Analyze the object through reference: On the references reference tab, you can see the reference relationship of the object. You can switch between incoming and outcoming to display the reference type:

Incoming indicates who referenced the object;

Outcoming indicates that other objects referenced by this object are displayed;

 

Select "show in graph" to display the reference relationship graphically. Select this object and click "show paths to GC root" to find the referenced root node. We can find that, the final reference of this hashmap segment object is in the concurrenthashmap and reentranlock objects; 8. by creating and analyzing this object: If Step 2 still cannot locate the memory leak, we can use the allocations tab to show how the object is created; we can check all the places where this object is used from the creation method until the leak location is found;

 

Use jprofiler for memory Analysis