Uncovering Memory Leaks Using NetBeans Profiler
Contributed by Jiri Sedlacek
This articles discusses how to use the NetBeans Profiler to locate memory leaks in a Java application.
What's a Memory Leak?
"Memory leak is a particular kind of unintentional memory consumption by a computer program where the program fails to release memory when no longer needed" as Wikipedia says. This can happen for any program written in any programming language and Java is no exception.
Many users think that the Java VM releases unused objects from memory automatically, but that's not always the case.
There are several scenarios when objects cannot be released and memory leaks occur.
One common scenario is when a single object with large memory consumption may be unintentionally held in memory,
for example a
How Can I Detect a Memory Leak?
In the first scenario, when a single (or few) object remains in memory after some action, memory leak detection is typically done by comparing memory snapshots taken before the action to snapshots taken after the action and then searching for unnecessary references to that object(s) in a heap walker tool.
This article will cover the second scenario, when there are many small objects that are continuously accumulating without being released.
This type of leak can be more difficult to detect because typically it's not related to any concrete action and does not use a
noticeable amount of memory until the program has run for a long time.
This scenario is dangerous especially with Java EE applications that are expected to run
for long periods of time.
After some time the leak starts to consume memory and may slow down performance of the
application or cause an
Even if your application seems to be working without any problems, before releasing your application it's always a good idea to verify that your application does not contain any potential memory leaks. For this purpose the NetBeans Profiler offers you special metrics which can reliably uncover large amounts of continuously leaking small objects - the Surviving Generations metrics. You can start the application in Monitoring mode without any profiling overhead and watch the graph to see if the application leaks over time.
What Do The Surviving Generations Metrics Mean?
Surviving Generations metrics cannot be easily defined with just one line, so let's make a three-line definition:
Typically there are several long-lived objects (like an application's main
Most applications also have short-lived objects which are created very frequently
If we merge the two above cases, the total number of Surviving Generations in typical applications is quite stable. You may have long-lived objects representing, for example, 3 Surviving Generations, and short-lived objects representing, for example, 5 Surviving Generations, which means there will be about 8 Surviving Generations during the application's runtime.
Of course, in some application, for example a Swing application, dialogs and other components are created during run time and as a result the number of Surviving Generations grows a bit. But after some period of time the number of Surviving Generations should become stable because all long-lived objects have already been created and newly-created short-lived objects are periodically being released from the heap.
However, if there is a memory leak in an application which prevents newly-created
objects from being released from the heap (for example objects stored in a
How To Do It With NetBeans Profiler?
The NetBeans Profiler is included as part of the regular installation of current versions of NetBeans IDE. If you are using an older version of the IDE that does not include all the profiler features (NetBeans IDE 6.1 or earlier) you might need to download and install the NetBeans Profiler installer package.
Discovering the Leak
If you discover a memory leak using the Surviving Generations metrics during monitoring, the NetBeans Profiler enables you to easily find the code in your application where the leaking objects are created and fix the problem.
Discovering the Source
To find the suspect code, perform the following steps.
Follow these steps to locate all the methods of your code where instances of the class are being created. The method(s) with the highest Surviving Generations value is most likely the cause of the leak.