« SOLUTION: Does this code have issues? | Main | The dangers of the InitialContext default constructor »

Memory Leaks made easy

Memory Leaks? We have a Garbage Collector!

True. Java comes with a Garbage Collector and makes reclaiming of heap space easier. On the other hand, Java offers a number of features, which, if used carelessly, can be the root for your memory leak nightmares.

Simple and Tempting

Since JDK 1.1 we have a quick, simple and tempting tool within the Core Language to create our own memory leaks. It doesn't matter whether we build server or standalone applications. This tool is called Inner Class. Together with its twin Anonymous Class both are very efficient in creating memory leaks.
public class Outer {
  class Inner {
  }
}

How is this?

Every non-static Inner Class has an implicit reference to its surrounding class. Anonymous Classes are similar. To successfully create a memory leak simply pass an Inner Class object to a method which keeps references to the provided objects and you're done.

Why?

Suppose you implement something like a cache. Next follow the execution path to a local object which stores some of its inner class objects into the cache. After the local object was out of scope, it won't be garbage collected anymore! The inner class object in the cache holds a reference to the surrounding object and that one is still referenceable and therefore not a candidate for garbage collection anymore. The same is true for anonymous classes!

How to prevent this style of Memory Leaks?

  • If you're about to use Inner Classes or Anonymous Classes think carefully. Don't use Anonymous Classes until you're very sure and can prove that they are not causing a Memory Leak.
  • Use a static Inner Class to get rid of the implicit outer class reference.

Comments (5)

There's a simple way to avoid this. Simply declare the inner class static, and it won't get that implicit reference to the outer class.

The flip side of this is that you no longer get access to the surrounding class' instance variables and / or methods.

Have you read about island of isolation? Garbage Collector could handle this situation already.

Kind Regards

Olaf Heimburger:

Marcos, you're right, a proper Island of Isolation is not problematic. The problem are overlooked references and that's why
Inner/Anonymous Classes are problematic because of the implicit reference...

pavan:

the cache should store a weak reference of the inner class object

Angelo vd Sijpt:

True, the implicit reference does keep some memory alive (how else would SuperClass.this work?), but this is not a memory leak. The outer object is kept in memory because the inner object can still use it; indeed, if you don't need it, declare the inner class static. In the end, the outer class is still reachable.

It would be a memory leak if the outer class would be unreachable, and still remain in memory (for instanced, by some circular reference, which is what the Island of Isolation that Marcos talked about is about), such as in non-garbage-collected languages, when deleting a pointer without releasing its heap space.

Still, I agree with you that "if you're not gonna use it, don't make it", so tell the compiler you don't need that reference.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About This Entry

This page contains a single entry from the blog posted on September 18, 2007 9:11 AM.

The previous post in this blog was SOLUTION: Does this code have issues?.

The next post in this blog is The dangers of the InitialContext default constructor.

Many more can be found on the main index page or by looking through the archives.

Top Tags

Powered by
Movable Type and Oracle