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 .