OutOfMemoryError Java Heap Space Fix - Heap Dump Analysis VisualVM Tutorial

In this tutorial I show you how and why a java.lang.OutOfMemoryError can occur when running a Java application. I also show you how to configure your application to perform a Java Heap Dump if an out of memory errors. Additionally; I perform heap dump analysis by importing it into a Java profiling tool such as VisualVM. This will help find the root cause.

First I set the Java Heap size to 64m by changing the –Xms and –Xmx virtual machine arguments.

What does –Xms stand for?
This java virtual machine argument allows you to specify the initial size (bytes) of the java heap.

What does –Xmx stand for?
This java virtual machine argument allows you to specify the maximum size, in bytes, of the memory allocation pool.

We set the java heap memory to such a small size that it can’t handle and save the amount of java objects being created. Once there is not enough memory left to allocate objects, the application will fail with an out of memory error.

I then configure the application to perform a Heap Dump on java.lang.OutOfMemoryError by specifying the flag:

XX:+HeapDumpOnOutOfMemoryError

This heap dump will be present in your applications working directory. If you would like to change the output path of the heap dump you can specify it by passing the:

-XX:HeapDumpPath

I then proceed to execute the java application which has an infinite loop that will create and place objects on an Array list. The application eventually fell over and threw an OutOfMemoryError when we allocated a Brick Object and tried to place it in the list. The list was at its maximum capacity and tried to resize. An arraylist is backed by an array, which has a finite number of elements. Each time the list’s backing array has reached maximum capacity it defines a new array typically double the size and copies the old array’s contents over into the new array. Then the GC clears the old array. Unfortunately there was not enough room for the new backing array in the Java Heap which caused the application to crash.

When the java failure occurred it left the java heap with file name pattern java_pid{process-id}.hprof, this file can then be imported into VisualVM Java profiler for analysis of the applications state when the out of memory error occurred.

After importing the hprof file into VisualVM profiler we can analyse the java thread’s status and the memory allocation. We can see the last stack trace before the failure and the huge amount of Brick allocations.

If your application ever crashes, it’s good to inspect the heap dump to find out what was going on. This will hopefully identify causes and will prevent future failures if you can put a fix in.

If you work with a cloud based ephemeral file system, then you might not be able to create / access a heap dump, as the application’s file system is scrapped and a new application is started on failure. There are ways to work around this such as attaching a hard drive to the instance. It depends on the nature of the system.

I hope you enjoyed the tutorial!

Don’t forget to subscribe for more great tech videos!

Thanks,
Philip

Eclipse VisualVM Launcher Integration Set-up Guide
youtube.com/watch?v=W60wvJ885iE&t

Java Heap Dump Analysis – VisualVM Tutorial
youtube.com/watch?v=Uubqc76h-jo

VisualVM
visualvm.github.io/

Eclipse Visual VM Integration
visualvm.github.io/idesupport.html

Java Profiling
docs.oracle.com/javase/7/docs/technotes/guides/…

What are the -xms and -xmx parameters when starting JVMs?
stackoverflow.com/questions/14763079/what-are-t…