not - Java todavía usa la memoria del sistema después de la desasignación de objetos y la recolección de basura

memory leak java

Question

Estoy ejecutando JVM 1.5.0 (Mac OS X predeterminado) y estoy supervisando mi programa Java en el Monitor de actividad. Tengo lo siguiente:

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Date;
public class MemoryTest {
public static void memoryUsage() {
System.out.println(
Runtime.getRuntime().totalMemory() -
Runtime.getRuntime().freeMemory()
);
}
public static void main( String[] args ) throws IOException {
/* create a list */
ArrayList<Date> list = new ArrayList<Date>();
/* fill it with lots of data */
for ( int i = 0; i < 5000000; i++ ) {
list.add( new Date() );
} // systems shows ~164 MB of physical being used
/* clear it */
memoryUsage(); // about 154 MB
list.clear();
list = null;
System.gc();
memoryUsage(); // about 151 KB, garbage collector worked
// system still shows 164 MB of physical being used.
System.out.println("Press enter to end...");
BufferedReader br = new BufferedReader(
new InputStreamReader( System.in )
);
br.readLine();
}

}

Entonces, ¿por qué la memoria física no se libera aunque el recolector de basura parece funcionar bien?

Answer 1

¿El sistema operativo quizás muestra la memoria que está asignada actualmente al programa? Aunque se asignan 150 ~ MB, esto no significa que se están utilizando 150 ~ MB.

Answer 2

Debe utilizar un generador de perfiles específico de JVM para supervisar el espacio de montón real que está utilizando el programa, en lugar de la memoria asignada a la JVM.

La JVM no solo es reacia a liberar la memoria de pila que asignó, sino que tiende a devorar espacio por diferentes motivos, incluida la compilación justo a tiempo.

Answer 3

Hay varias opciones de línea de comandos para JVM que ayudan a ajustar el tamaño del montón utilizado por Java. Todo el mundo sabe (o debería saber) sobre -Xms y -Xmx, que establecen el tamaño mínimo y el máximo del montón.

Pero también está -XX: MinHeapFreeRatio y -XX: MaxHeapFreeRatio, que son los límites respectivos entre los que la JVM gestiona el espacio libre. Hace esto reduciendo el montón utilizado y puede reducir el consumo de memoria del programa.

Puedes encontrar más información aquí:

• Sun Java System Application Server Enterprise Edition 8.1 2005Q1 Performance Tuning Guide, Capítulo 4
• Tuning Garbage Collection Outline , por Pete Freitag

Answer 4

Muchas JVM nunca devuelven memoria al sistema operativo. Si lo hace o no, es específico de la implementación. Para aquellos que no lo hacen, los límites de memoria especificados al inicio, generalmente a través del indicador -Xmx, son los principales medios para reservar memoria para otras aplicaciones.

Me está costando encontrar documentación sobre este tema, pero la documentación del recolector de basura para Java 5 de Sun sí lo hace, lo que sugiere que, en las condiciones adecuadas, el almacenamiento se reducirá si se utiliza el recopilador correcto, de manera predeterminada, si supera los 70 % del montón es gratis, se encogerá de modo que solo el 40% es gratis. Las opciones de línea de comando para controlarlas son -XX:MinHeapFreeRatio y -XX:MaxHeapFreeRatio .