How to Create a Memory Leak in Java

How can I create a memory leak in Java?

Here's a good way to create a true memory leak (objects inaccessible by running code but still stored in memory) in pure Java:

1. The application creates a long-running thread (or use a thread pool to leak even faster).
2. The thread loads a class via an (optionally custom) ClassLoader.
3. The class allocates a large chunk of memory (e.g. new byte[1000000]), stores a strong reference to it in a static field, and then stores a reference to itself in a ThreadLocal. Allocating the extra memory is optional (leaking the class instance is enough), but it will make the leak work that much faster.
4. The application clears all references to the custom class or the ClassLoader it was loaded from.
5. Repeat.

Due to the way ThreadLocal is implemented in Oracle's JDK, this creates a memory leak:

• Each Thread has a private field threadLocals, which actually stores the thread-local values.
• Each key in this map is a weak reference to a ThreadLocal object, so after that ThreadLocal object is garbage-collected, its entry is removed from the map.
• But each value is a strong reference, so when a value (directly or indirectly) points to the ThreadLocal object that is its key, that object will neither be garbage-collected nor removed from the map as long as the thread lives.

In this example, the chain of strong references looks like this:

Thread object → threadLocals map → instance of example class → example class → static ThreadLocal field → ThreadLocal object.

(The ClassLoader doesn't really play a role in creating the leak, it just makes the leak worse because of this additional reference chain: example class → ClassLoader → all the classes it has loaded. It was even worse in many JVM implementations, especially prior to Java 7, because classes and ClassLoaders were allocated straight into permgen and were never garbage-collected at all.)

A variation on this pattern is why application containers (like Tomcat) can leak memory like a sieve if you frequently redeploy applications which happen to use ThreadLocals that in some way point back to themselves. This can happen for a number of subtle reasons and is often hard to debug and/or fix.

Update: Since lots of people keep asking for it, here's some example code that shows this behavior in action.

Causes of memory leak in java

However, this question is far too crude to get a completely correct answer here. I have only shown you common behavior patterns.

What is a memory leak?

A Memory Leak is a situation when there are objects present in the heap that are no longer used, but the garbage collector is unable to remove them from memory and, thus they are unnecessarily maintained. A memory leak is bad because it blocks memory resources and degrades system performance over time.

What causes memory leaks in Java?

The first scenario that might cause a Java memory leak is referencing a heavy object with a static field. We created our ArrayList as a static field – which will never be collected by the JVM Garbage Collector during the lifetime of the JVM process, even after the calculations it was used for are done.

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:

File/Text buffers not closed.

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) { e.printStackTrace(); }
    }
}

How to 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).

A simple program to demonstrate memory leak in Java

http://www.codeproject.com/KB/books/EffectiveJava.aspx

See Item 6.

Easiest way to cause a memory leak in Java

You cannot really "leak memory" in Java unless you:

• intern strings
• generate classes
• leak memory in the native code called by JNI
• keep references to things that you do not want in some forgotten or obscure place.

I take it that you are interested in the last case. The common scenarios are:

• listeners, especially done with inner classes
• caches.

A nice example would be to:

• build a Swing GUI that launches a potentially unlimited number of modal windows;
• have the modal window do something like this during its initialization:
  

  
  StaticGuiHelper.getMainApplicationFrame().getOneOfTheButtons().addActionListener(new ActionListener(){
  public void actionPerformed(ActionEvent e){
  // do nothing...
  }
  })
  

The registered action does nothing, but it will cause the modal window to linger in memory forever, even after closing, causing a leak - since the listeners are never unregistered, and each anonymous inner class object holds a reference (invisible) to its outer object. What's more - any object referenced from the modal windows have a chance of leaking too.

This is why libraries such as EventBus use weak references by default.

Apart from listeners, other typical examples are caches, but I cannot think of a nice example.

Java memory leaks?

A memory leak in java is caused by keeping a reference into a object that you thought you deleted but you left one or more references that provides a path to the object from a root GC (for instance a static object). That means the JVM has to assume that the object might be accessed in the future. It does not know that programmer doesn't need the object anymore.

It's sort of like forgetting to free memory in C/C++. The difference here is that you forgot to remove a reference to it rather than freeing the object itself.

Read more about it here: http://www.w3resource.com/java-tutorial/garbage-collection-in-java.php

You can see examples of memory leaks here: Creating a memory leak with Java

WebSphere 8 memory leaks

Using RestTemplate instead of SOAPConnection fixed the memory leaks :

   final RestTemplate restTemplate = new RestTemplate();
            final HttpHeaders headers = new HttpHeaders();
            headers.add("Content-Type", "text/xml");
            final HttpEntity<String> request = new HttpEntity<>(message, headers);
            final String result = restTemplate.postForObject(wsUrl, request, String.class);
            return result;

---

Related Topics