One of the problems with discovering a memory leak is that even if the symptoms are strong and don’t leave much room for doubt, the interpretation of the memory usage measurements is always specific to your Java application. That is why it is important to understand the concept of memory leaks, and use it in the context of your Java application.
What is a “Memory leak” in Java?
Let us start with outlining what is the difference in the memory management in Java and, for example, C languages. When a C-programmer wants to use a variable, he has to manually allocate a region in the memory where the value will reside. After the application finishes using that value, the region of the memory must be manually freed, i.e. the code freeing the memory has to be written by the developer. In Java, when a developer wants to create and use a new object using, e.g. new Integer(5), he doesn't have to allocate memory – this is being taken care of by the Java Virtual Machine (JVM). During the life of the application JVM periodically checks which objects in memory are still being used and which are not. Unused objects can be discarded and memory reclaimed and reused again. This process is called garbage collection and the corresponding piece of JVM is called Garbage Collector, or GC.
A definition, some musings and even a code sample: Click here to read further.