Memory Management 

Automatic memory management offered by Java makes development much easier because references do not have to be tracked by the application itself. As soon as an object is not referenced by a variable, it is ready to be reclaimed by the garbage collector built into the JVM. As a result, there is no way to reference objects once the memory has already been released. This solves the problem of dangling references known in languages with manual memory management.

The problem that arises is that objects that are not used anymore can only be released when there are no longer referenced. Keeping references to unused objects cause memory leaks.

The Java memory management has the following basic rules:

·        Every object in the JVM has a counter containing the number of variables that actually refer to it.

·        Objects are released by the garbage collector when they are no longer referenced - that is when the counter is zero, because the object cannot be accessed anymore.

·        When an object (including class objects) is released by the garbage collector, all references contained in the member variables of the object are discarded too (the reference counter of the referred objects is decremented). When a class is released (because there is no more instance of the class in the system), all static members containing references are also cleared. So further objects can be released by the garbage collection.

·        The garbage collector is working asynchronously, in a separate (low-priority) thread. Therefore the instant the memory is reclaimed cannot be predicted as it depends on several factors (system-load, available memory and so on).

There are different garbage collector implementations available and the strategy is much more sophisticated. For more details see:

http://developers.sun.com/techtopics/mobility/midp/articles/garbage/

Memory Leaks

Memory leaks are created by keeping a reference to objects that are not in use any more. Often, container objects (like the Java Collection Classes) are the source of such leaks. All objects or classes that are used to collect information are candidates for memory leaks. Especially static variables are dangerous, because the class object itself is not released by the garbage collector. This has to be kept in mind when static lists or maps are introduced.

Example:

Maps (like HashMap or Hashtable) are used when information I has to be associated with an object instance X, mapping the key X to the value I. As soon as the corresponding object X is not used anymore, the entry (X à  I) in the map has to be removed, otherwise X will stay in the map and the garbage collector recognizes the still existing reference to the map entry. The concept of weak references helps to resolve these issues. For more details see:

http://java.sun.com/developer/technicalArticles/ALT/RefObj/

Garbage Collection Slowdowns

In Java every object resides in the heap (in dynamic memory). Java treats all objects by reference. There are no local objects on the stack (compared to local variables of basic type that disappear when their scope is gone). As a result even temporary objects that are used only for a short period of time are subject to dynamic memory management and therefore garbage collection.

This leads to the situation where programs that create a lot of temporary objects put an enormous load on the garbage collection thread. A backlog of garbage objects is building up and the available memory is going down. Eventually the garbage collector has to interrupt the program execution to clean up the backlog. This is called full garbage collection. This kind of emergency reaction is responsible for long delays in the response time, sometimes even more than a minute with no visible progress.

Example of excessive garbage creation (see also Built-in Types):

String contents = "";      InputStream is = url.openStream();      int c;      while((c = is.read()) != -1) {         contents += c;  // creates a new object      }

For each transferred character a new string is created and assigned to the variable contents. For a file that has N characters, N x (N/2) x r bytes of garbage memory will be created and has to be reclaimed by the garbage collector.

The JVM option –verbose:gc monitors the behavior of the garbage collection and can help to spot memory leaks.