Memory Leaks in JAVA

When we write programs, memory management is the bottleneck issue on performance.

JAVA handles memory management through Garbage Collection. You were promised that Garbage Collection (GC) in Java will relieve you from the mundane duties of allocating, tracking, and freeing the heap memory. Indeed, the promise has been delivered, Yes Its true.Garbage collection is one of the powerful features of  JAVA. so it is reasonable — and to quite an extent correct — for you to conclude that there will be no memory leaks in your Java program. However, the catch is that GC can take care of only typical heap management problems.

We often hear programmers saying that JVM takes care of Garbage collection and programmers don’t need to worry on them. But, there are situations where memory leaks can still occur.

Common memory leak causes in Java

 Java may not have pointers. but memory leaks still happen. You can easily consume most of your memory on the heap if you’re not taking care to free up memory you no longer need. The possibility for memory leaks seems to go up dramatically the more programmers work on a single project. This is especially true if some don’t fully understand the java memory model.

In this post I’m going to point the most common scenarios likely to cause a memory leak.Common causes of memory leaks in Java

1) Static variables

Many junior programmers in java do not fully understand what static means. This misunderstanding is perhaps the most common cause of unintended memory leaks. To understand static variables, think of the scope of a variable, or, where does a variable live? If you declare a variable inside a  method, this is called a method scoped variable. It only exists while that method is running and is usually destroyed and released for garbage collection as soon as the method exits. If you declare a variable inside a class definition, then it is OBJECT scoped. It is NOT CLASS SCOPED. Remember a class is a blueprint for an object, and an instance of an object is completely different then the class from which it was built. The variable that is object scoped will be deferenced and ready for garbage collection as soon as all references to the object are destroyed. When you null out the only reference to an object, it is properly deferenced.

STATIC VARIABLE is CLASS SCOPED. A static variable lives on the blueprint of an object, not the object itself. The classes in java are usually loaded right away at startup and are never deferenced until you shut down the JVM. If you declare a variable as static it will live for the entire lifetime of the JVM, unless it is individually nulled out. If a static variable references non static objects, it effectively makes those objects static as well. You can clear out a static collection, but depending on how the collection is cleared you may or may not be freeing up memory. Be careful. If you don’t understand why something needs to be static, ask someone who does understand. Static is a surprisingly sticky subject and many career programmers still don’t fully understand what it means.

2) Poorly implemented data structures

Poorly implemented data structures can be just as damaging and confusing as either of the other two common issues.  When you store data in a common array, you have to null out the indices of the array if you want the objects contained within to be deferenced. A seemingly simple thing like that can become easily obfuscated and forgotten when implementing a complicated data structure, like a specialized tree or specialized hash table.

The best thing to do in most scenarios is try to encourage the use of standard data structures (usually through sun or apache) that have been used by many people, thoroughly tested, and de-bugged.

You will sometimes run into career developers who have spent too much time implementing their own vector class or their own tree structures to ever consider using the standard tools. In fact, many of these ‘blinded by undeserved ego’ types will not even know of the common classes developed a decade ago. If you find yourself debugging memory leaks in your co-workers data structures to often, consider looking for a different development group to be apart of, or a different company. It’s good to have a grounded understanding of how all the major data structures work, it’s bad to assume that everything you do will somehow be magically better than other (almost always smarter) professionals.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: