Creating a memory leak with Java

Question

Anonymous User · Accepted Answer

"Here's a good way to create a true memory leak (objects inaccessible by running code but still stored in memory) in pure Java:The application creates a long-running thread (or use a thread pool to leak even faster).The thread loads a class via an (optionally custom) ClassLoader.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.The thread clears all references to the custom class or the ClassLoader it was loaded from.Repeat.This works because the ThreadLocal keeps a reference to the object, which keeps a reference to its Class, which in turn keeps a reference to its ClassLoader. The ClassLoader, in turn, keeps a reference to all the Classes it has loaded. It gets worse because in many JVM implementations Classes and ClassLoaders are allocated straight into permgen and are never GC'd at all.A variation on this pattern is why application containers (like Tomcat) can leak memory like a sieve if you frequently redeploy applications that happen to use ThreadLocals in any way. (Since the application container uses Threads as described, and each time you redeploy the application a new ClassLoader is used.)Update: Since lots of people keep asking for it, here's some example code that shows this behavior in action."

Anonymous User · Answer

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

The application creates a long-running thread (or use a thread pool to leak even faster).

The thread loads a class via an (optionally custom) ClassLoader.

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.

The thread clears all references to the custom class or the ClassLoader it was loaded from.

Repeat.

This works because the ThreadLocal keeps a reference to the object, which keeps a reference to its Class, which in turn keeps a reference to its ClassLoader. The ClassLoader, in turn, keeps a reference to all the Classes it has loaded. It gets worse because in many JVM implementations Classes and ClassLoaders are allocated straight into permgen and are never GC'd at all.

A variation on this pattern is why application containers (like Tomcat) can leak memory like a sieve if you frequently redeploy applications that happen to use ThreadLocals in any way. (Since the application container uses Threads as described, and each time you redeploy the application a new ClassLoader is used.)

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

forum

Creating a memory leak with Java

Can you answer this question?

1 Answers