A Java Memory Leak !

How come a memory leak can happen in JAVA as there a worker that do its job i.e. GC

GC, depends on the type selected (parallel gc,serialgc..refer to typesofGC.doc) does the job of cleaning the memory and moves objects in the spaces… However there will be some instances where unused reference objects that remains in memory till the main program exists as these programs are not called off in the main program..

Given the above conditions, not always an increasing heap usage suggests a memory leak ! Yes, GC won’t really perform a major/full GC unless it is required. And for some programs, even after exiting the load the GC won’t really perform the full GC as there will be still space for moving objects and new generations…

We may say memory leak is there when we see ‘OutofMemory’ exceptions in the logs OR some times the leak is very minimum so that it will not result in OOM exception so quickly. Also, be noticed OOM is not always a symptom of mem leak as it can happen when the basic enough memory is not there for the applications to start or what it has to be under rampup..

So, a best way to CONFIRM mem leak is by observing the Heap after two full GC activity as there will be a slight(depends) in increase in the base memory occupied in the Heap after the full GC. But this need to done under after reaching steady state.. Also, one has to note that this Major or Full GC (clearing old/tenured space), depending on the full gc algorithm, the full GC size can vary i.e. some times it waits to a specific threshold in Old space and performs a full gc and some other times it waits till more old gen space gets filled to perform a full gc.. However, if there is a (heap) memory leak, then what ever varying full gc happening over a long run you should see increasing base heap memory .. and may eventually turns up into OOM after 1 hour/1day/10days..!!

And there are some special category objects called roots which are special objects which GC won’t collect. The roots will into the below mentioned categories..

· Class - class loaded by system class loader. Such classes can never be unloaded. They can hold objects via static fields. Please note that classes loaded by custom class loaders are not roots, unless corresponding instances of java.lang.Class happen to be roots of other kind(s).

· Thread - live thread

· Stack Local - local variable or parameter of Java method

· JNI Local - local variable or parameter of JNI method

· JNI Global - global JNI reference

· Monitor Used - objects used as a monitor for synchronization

· Held by JVM - objects held from garbage collection by JVM for its purposes. Actually the list of such objects depends on JVM implementation. Possible known cases are: the system class loader, a few important exception classes which the JVM knows about, a few pre-allocated objects for exception handling, and custom class loaders when they are in the process of loading classes. Unfortunately, JVM provides absolutely no additional detail for such objects. Thus it is up to the analyst to decide to which case a certain "Held by JVM" belongs.