How to find and fix memory leaks in your Java application

Memory increase

Do you have a Java application that runs fine at first but slows down after a while, or it runs fine for a small number of files but performance degrades for large number of files? Maybe you have a memory leak.


When fixing memory leaks; If someone were to ask me: “If you knew back then what you know now, what would you tell yourself?”. Well, I would say…..

Target Audience

While in general the approach described in this article is IDE & OS independent, I used Linux [Fedora] and Eclipse [Plugin development] in the screenshots & instructions.

Symptoms of a Memory leak

Works fast at first, but slows over time.

  •  Works fine with small data sets, severe performance issues with large data sets
  •  Ever increasing Old-Generation memory usage in your JVM
  •  Out-of-Memory Heap errors in your JVM
  •  Spontaneous crashes.

Common Memory leaks

A memory leak in Java (who would’ve thought heh?) can occur if you forget to close a resource, or a reference to an object is not released. e.g.

  • File/Text buffers not closed. (as was in my case)
  • Hash maps keeping references alive if equals() and hashcode() are not implemented, e.g.
    import java.util.Map;
    public class MemLeak {
    public final String key;
    public MemLeak(String key) {
        this.key = key;
    public static void main(String args[]) {
        try {
          Map map = System.getProperties();
          for(;;) {
             map.put(new MemLeak("key"), "value");
        } catch(Exception e) {


  •  Inner classes that reference outer classes can leak. (make them static to avoid).

How does one go about fixing them?

There are two approaches. The first is a ‘quick fix’ attempt. If that fails then you’ll have to go down the long road.

  • 1) Quick fix: Eclipse Memory Leak Warnings (catches some leaks)
  • 2) Manually disable & enable parts of your code and observe memory usage of your JVM using a JVM tool like VisualVM (or Jconsole, or Thermostat).

1) Quick fix: Eclipse Memory Leak warning/errors.

For code with JDK 1.5+ compliance, eclipse will throw warnings and errors at you for obvious cases of leaks. To be more precise, anything that implements closable (since 1.5) (e.g outputstream since 1.5) will throw a warning at you if its reference is destroyed but the object is not closed. However, the leak-detection isn’t always enabled in eclipse projects. You might have to turn them on first. Go to your project settings and enable them as demonstrated:

Enable Leak detection in eclipse

Now eclipse will outline memory leaks:

Potential Memory leak

However, even with fancy Eclipse hocus pocus, not all file closures and leaks are detected. Especially when working with legacy (pre 1.5) code, you’ll likely run into leaks because those were written before ‘closable’ was implemented. Or sometimes file opening/closures are nested so deeply that eclipse won’t detect them.  If you’re in this place, you may want to try step 2.

2) Manually disable & enable parts of your code and observe memory usage of your JVM using a JVM tool like VisualVM.

If you got this far then you’ll have to roll up your selves and do some manual labor. You could read all of your code and try to understand where the leak occurs. To help you with this process: I recommend to try using a tool like VisualVM.  (But Thermostat and MAT also work.)

Configure VisualVM

  1. Download the tool
  2. Open terminal, navigate to …/visualvm_xyz/bin run the shell script './visualvm'   (or visualvm.exe on windows).
  3. You should see the main window.  If you expand ‘local’ and double click on your running application (a child eclipse in my case), you can see its properties. visual vm main
  4. Troubleshooting VisualVM on Fedora (skip this if it works well:  For me, initially I couldn’t connect to my JVM’s, I couldn’t take heap-dumps and profiling didn’t work either. Here are some steps that might help:
    • Make sure that you run it as your own user and not sudo.
    • Perform a full update of your system (sudo yum update).
    • Reboot helps 🙂
    • Try to close all running Java applications. Launch VisualVM, then try your luck again.
  5. Add some plugins. Before VisualVM became useful to me, I first had to add some plugins. Go to Tools -> Plugins -> ‘Available Plugins’. Select these plugins (feel free to browse and add more if you like):
    • Memory Pools
    • Visual GC
    • Kill Application

Analyze running code with visualvm

  1. Now run your Java application,
  2. Attach VisualVM to your application.
  3. Perform the operation that causes the sluggish performance.
  4. Inspect the ‘Monitor’ and the ‘memory pools‘ tab. If you see that your memory increases in the ‘Monitor’ tab, try  pressing ‘Perform GC’ (garbage collection) and see if that decreases memory usage.   Copyright out of memory _ANNO If not…
  5. Then switch over to the ‘memory pools’ tab and inspect the ‘Old Gen’. (Objects first hang around in “Eden”, then transition through Survivor spaces, older objects move into the ‘Old Gen’ Pool. If something leaks, it’ll be in the Old-Gen pool. Details) Visual Vm meam leak _anno
  6. Now go back and comment out most of the code of your program to the point where the application just start & stops.
  7. Repeat until the application doesn’t leak at all.
  8. Then through several iterations re-enable parts of your code and inspect VisualVM memory usage. When your application starts to leak again, go into the method that caused the memory leaks and narrow down further.
  9. Eventually you’ll narrow down the problem to a single class, perhaps even a single method. Once you’re there, carefully validate that all file-buffers are closed and Hashmaps are used properly.

Benchmarking your code

Sometimes it’s hard to tell if your shiny new code is any better than the old code. In this case you may want to benchmark the performance of your application. Here is some code that you can insert into the right place to get info about run-time and number of garbage collection runs:

long start = System.currentTimeMillis();
 //your code
long end = System.currentTimeMillis();
System.out.println("Run time: " + Long.toString(end - start));

public static String printGCStats() {
 long totalGarbageCollections = 0;
 long garbageCollectionTime = 0;
 for (GarbageCollectorMXBean gc : ManagementFactory.getGarbageCollectorMXBeans()) {
 long count = gc.getCollectionCount();

 if (count >= 0) {
 totalGarbageCollections += count;

 long time = gc.getCollectionTime();

 if (time >= 0) {
 garbageCollectionTime += time;
 return "Garbage Collections: " + totalGarbageCollections + "n" +
 "Garbage Collection Time (ms): " + garbageCollectionTime;

As a note, if you test in your main Eclipse, it’s recommended to test in a ‘clean’ child Eclipse instead. Or in some ‘clean’ instance of your Eclipse, because other plugins will get in the way of accurate timing.

Additional help: Heap dumps

I personally haven’t used this much, but folks rave about ‘Heap-dumps’. At any time, you can take a heap-dump and then see how many  instances of classes are open and how much space they utilize. You can double click on them to see their content. This is useful if you want to see how many objects your application generates.

Visual Vm Heap dump _Anno

Hold on, my application doesn’t have leaks but it’s still slow?

It’s possible that you don’t have any leaks in your code, but it’s still very slow. In this case you’ll have to profile your code. Code profiling is out of the scope of this article, but there is a great youtube lecture that explains how you can profile with Eclipse using free and paid profilers.

Where to go from here?

At this stage, try to spend a day or two actually fixing your memory leak. If you still have troubles, try reading some of these articles:


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

  • That’s such a good article which presents complete information about how to detect and set up memory leaks in Java application with its coding and object lesson.

    • Leo Ufimtsev

      Thank you :-). Feel free to ping me if you have questions or if I missed something.

  • Pingback: Java Annotated Monthly – September 2014 | JetBrains IntelliJ IDEA Blog()

  • Rahul Deo

    Great Dude ! Really, awesome explanation …

  • Rajesh

    It is gr8 article

  • Great Great, Very crisp for a begginer like me !
    Good luck to you !

  • Pingback: Unable to resolve memory leak of MongoDb cursor in Java - BlogoSfera()

  • T

    This really only works if the program is quite small.
    We have about 100,000 lines of our own code, spread out in over 500 classes. Also, our code is used in combination with a big framwork, that consists of about 200 jars (own and 3rd party).

    • Well, general debugging scales like binary trees. At the first level you determine if it’s in the first 50,000 lines of code, or in the other 50,000 lines of code. Then you determine in which 25,000k of code you have the issue. Then you narrow it down to 12.5k lines of code etc… Sort of like git-bisect.
      The idea here is to be able to see if the JVM is leaking memory or not.

      There isn’t really an algorithmic approach to finding memory leaks that scales indefinitely that I’m aware off, but if you find something that scales well, please feel free to post up something :-).

  • Pingback: Java Details | saipraveentechblog()

  • Pingback: find-fix-memory-leaks-java-application – achyut1990's Blog()