java.lang.OutOfMemoryError: Java heap space

Fuentes:
http://www.saiyine.com/post.798.php
http://www.consultoriajava.com/publico/JavaHeapSpace.shtml
http://hausheer.osola.com/docs/5

Si tu programa en Java se queda sin memoria suficiente, tiene lugar el siguiente error:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Se puede deber a dos motivos:

* Que tu aplicación en Java tenga una perdida de memoria. Toca buscar el problema en el código, en breve os haré un post comentando el profiler que suelo usar, que me parece genial aunque a 400€ por licencia no creo que esté al alcance de todo el mundo.
* Que tu programa realmente necesite un montón de memoria. En este caso, la memoria disponible la puedes incrementar llamando a la maquina virtual con estos parametros:

java -Xms -Xmx

Por defecto tenemos:

java -Xms32m -Xmx128m

Estos parametros se pueden pasar en diferentes puntos dependiendo del entorno que utilicemos para programar.

Otro:

Este error se puede producir por diversos motivos, un programación poco eficiente es el motivo más grave y en ocasiones es conveniente un proceso de refactorización.

Sin embargo en determinadas circunstancias se puede evitar este fallo grave ampliando el espacio de la zona de intercambio, esto se hace con los siguientes parámetros de la JVM (Máquina virtual de Java):

-Xms 

Por ejemplo: -Xms6291456, -Xms6144k, -Xms1500M

-Xmx

Por ejemplo, -Xmx83886080, -Xmx81920k, -Xmx1500M

Obviamente la cantidad de memoria que puedas emplear estará limitada por tu propia maquina, al emplear este tipo de opciones ten un poco de cuidado por que según que SSOO estés usando podrias saturar su memoria y disminuiria su rendimiento.

Si ves que ampliando la sección del área de intercambio no se resuelve tu problema, entonces existen otras soluciones más agresivas.

Otro:

If Java runs out of memory, the following error occurs:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

This can have two reasons:

• Your Java application has a memory leak. There are tools like YourKit Java Profiler that help you to identify such leaks.
• Your Java application really needs a lot of memory (more than 128 MB by default!). In this case the Java heap size can be increased using the following runtime parameters:

java -Xms -Xmx

Defaults are:

java -Xms32m -Xmx128m

You can set this either in the Java Control Panel or on the command line, depending on the environment you run your application.

Otro: http://forums.java.net/jive/thread.jspa?messageID=216415

Thankx for ur suggestion... ny wy my problem is not with GC info, every thing is working fine for me in that aspect, I can see the same behaviour while Im using JProbe (Profile while testing). Id like explain problem is as follows :

We have observed a new behavior in jdk 1.6 while testing . i.e., when a service is started with custom Memory arguments ( -Xms, -Xmx) which refers to HEAP memory, as per the SUN documentation the behavior must be as follows :

1. If we configure MIN and MAX memory to have a range, say MIN=64M and MAX=512M, then initially the service will occupy only 64M and later scale upto 512M on demand. This approach is having its own disadvantages as it creates more stress on JVM while scaling upto MAX.

2. If we configure MIN and MAX to the same number, then the entire memory is available to the JVM right from the start. JVM will not release the assigned memory, even if there is no activity.

We have a practice of configuring MIN and MAX to the same amount in majority of cases and it behaved as expected until jdk 1.5. And now for jdk 1.6 we observed a new trend. i.e., even if the Application is configured to have MIN and MAX values configured to the same value, JVM is only using a part of it (say 10%) when the Service is Idle(no activity).

This is causing the false alarm in the application,

Let me explain the case in details,
We configured MIN and MAX to 768MB, start the service. Now observe that the process iniatlly occupies all the Memory (say 650M, we refer to this as CAPACITY memory) and if there is no activity on the service for a period of time (say 30 min - 1 Hr), JVM performs a FULLGC and from there onwards the CAPACITY memory is cut down to 29M in which 22MB is used and 7MB free (please refer the snapshot below).

This is an intelligent behavior as far as JVM is considered;) but Runtime.getRuntime().freeMemory() ( This is the logic implemented in our Application ) will give only the Free Space which is Committed to JVM, thereby we have a False Alarm. To avoid this we need to change the logic to evaluate Free memory on the Box ( i.e., MaxHeap -Capacity + Free = Actual Free Memory avilable to JVM).

Heap memory is a part of physical memory ie., RAM. When you allocate heap size using -Xms and -Xmx your kernel will not allocate whole of the MINIMUM size to your java process. The -Xms and -Xmx is you are telling to the kernel that your process may require -Xms MINIMUM memory and -Xmx MAXIMUM memory and that MIN and MAX is Virtual. Only on demand the memory pages are allocated to your java process.

The reason why most people set MIN and MAX to same value is to avoid frequent Heap Shrinkage and Heap Growth. Frequent shrink and growth is an overhead.