Tuesday, March 25, 2014

Java Memory Leaks-Performance testing

My following posts explains about How to find Java memory leaks during performance testing , for now this post will explain about what is Java memory leak and how Java memory management will be ?

1.          About Java Memory Leak & why they happen?

Have you ever seen this situation?

  If the answer is yes, you may have a case of memory leak induced in your application, but fortunately we've got a cure for what ails you.


Above Error message Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory and no more memory could be made available by the garbage collector.
An OOM or OOME (OutOfMemoryError) simply means that the JVM ran out of memory. When this occurs, you basically have 2 choices:
  • Allow the JVM to use more memory using the -Xmx VM argument. For instance, to allow the JVM to use 1 GB (1024 MB) of memory:
Java -Xmx1024m...

  • Improve/Fix the application so that it uses less memory
In many cases, like in the case of a memory leak, the second option is the only sound choice. A memory leak happens when the application keeps more and more references to objects and never releases them. The garbage collector will therefore never collect those objects and less and less free memory will be available until we reach the point where not enough free memory is available for the application to function normally. At this point, the JVM will throw an OOM.

How JVM Allocates Memory:
Let’s have a look at the Sun Hotspot JVM implementation as an example:




Java Heap space is divided into three regions or generation for sake of garbage collection - New Generation, Old or tenured Generation or Perm (permanent) Space. JVM allocates every generation its own memory pool. The JVM has at least one memory pool and it may create or remove memory pools during execution.
  1. Eden Space (heap - young generation):
    1. Pool from which memory is INITIALLY allocated for most objects.
  2. Survivor Space (heap - young generation):
    1. Pool containing objects that have survived GC of Eden space.
  3. Tenured Generation (heap - old generation):
    1. Pool containing objects that have existed for some time in the survivor space.
  4. Permanent Generation (non-heap - stack):
    1. Holds all the reflective data of the virtual machine itself, stores class level details, loading and unloading classes (e.g. JSPs), methods, String pool.
  5. Code Cache (non-heap):
    1. Hotspot JVM also includes a "code cache" containing memory used for compilation and storage of native code.
My next post will have how to find memory leak using various JDK Tools....

No comments:

Post a Comment