Java Heap Analysis – Series Part Two

Leave a comment

james_cavazosby James Cavazos, Senior Performance Engineer

In Part One of the Java Heap Analysis blog we monitored the heap and created a heap dump. In Part Two we will look into analyzing the heap and how to determine the cause of the leak.

Analyzing the heap dump

Now that we have a heap dump we can analyze it. You will need to transfer the heap dump to your local machine. These files can be large depending on the size of your heap. It is not uncommon to be several GB in size. I recommend putting each heap dump in its own directory. This is because the analyzer creates several files in the same directory as the heap and this could get confusing when you are cleaning up.

For analyzing the heap, I recommend using a more advanced tool than what comes with the JDK. The JDK has JHat which gives you a difficult to use Web interface that is slow and clunky with no advanced tools. If you don’t have in-depth java programming knowledge it is mostly useless. I recommend using Eclipse’s Memory Analyzer: http://www.eclipse.org/mat/.

You will need a machine that has enough memory to open the heap especially if they are in the GBs. I also recommend a 64-bit OS and 64-bit version of MAT.

Start MAT and open the heap file using “Open Heap Dump…” to get started. This will parse the heap and create several files in the directory where the heap is. You will notice that MAT will prompt you to run a report in the getting started wizard. The first report listed is “Leak Suspect Report”. This report will try to determine what is causing the leak. In most cases, this will help narrow down the possible causes of the leak. It will usually return a handful of suspects ordered by heap usage percentage. Depending on the complexity of the application, the number of suspects can be from one to four or more.

In the sample Leak Suspect Report above, we see that it found only one suspect and it is taking 99.21% of the heap. The sample application was very simple so this is expected. A detailed description is available through the details link at the bottom.

In the detailed report, we can see the suspect object and the child objects. In the dominator tree, we see the main thread has 99.21% of the heap. This percentage value is cumulative of all the child objects and the parent. The child object of class Vector and Object[] also have the same percentage, meaning almost all of the heap usage is from the Object array within the Vector. We also see that the array has 2,621,440 objects in it, all of which are Strings.

Without looking at the code, we can infer the probable cause. Either objects being added to the Vector are not being removed as they should, the Vector was supposed to be cleared or destroyed at some point and wasn’t or the objects in the Vector that were supposed to be updated were getting added again. There are likely other possibilities as well, but you will have provided useful information to your team by doing a little digging.

Another approach is to look at the dominator tree of the entire heap. To access this, click on the third icon in the heap display window.

This is similar to the leak suspect dominator tree except this is showing all objects in the heap. This is useful if the leak report failed to show anything conclusive.

For performance testers needs, this should be enough to give your team a good direction to start their investigation. It also helps you better understand the application you are testing. Problems such as memory leaks will require you to work closely with the development team. Being able to monitor heap status and reproduce the conditions to create the memory leak will help to reduce the amount of time needed to both detect and verify fixes to the code.

Sample Java code to create memory leak:

package examples;
import java.util.UUID;
import java.util.Vector;
import java.lang.Thread;

public class MemoryLeak {

	public static void main(String[] args) throws InterruptedException {
		Thread.sleep(60000);
		Vector v = new Vector();
		while (v.size()>=0)
		{	
			for (int i=0; i<10000; i++)
			{
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
				v.add(UUID.randomUUID().toString());
			}
			System.out.println((new java.util.Date()).toString());
			Thread.sleep(30000);
		}
	}
}

Remember, even the most experienced engineer can slip a memory leak into their code. Knowing how to spot one and debug the issue and being able to supply needed data is crucial.

Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s