Java 6 Uso Excesivo De La Memoria

En respuesta a un debate en los comentarios a Ran respuesta, he aquí un caso de prueba que demuestra que la JVM va a liberar a su memoria el sistema operativo bajo ciertas circunstancias:

public class FreeTest
{
    public static void main(String[] args) throws Exception
    {
        byte[][] blob = new byte[60][1024*1024];
        for(int i=0; i<blob.length; i++)
        {
            Thread.sleep(500);
            System.out.println("freeing block "+i);
            blob[i] = null;
            System.gc();
        }
    }
}

Veo la JVM proceso de disminución de tamaño cuando el conteo llega a alrededor de 40, en tanto en Java 1.4 y Java 6 Jvm (del Sol).

Usted puede incluso ajustar el comportamiento exacto con el -XX:MaxHeapFreeRatio y -XX:MinHeapFreeRatio opciones -- algunas de las opciones de la página también pueden ayudar a responder la pregunta original.

Yo no sé acerca de los errores de página. pero se trata de la enorme memoria asignada para Java:

1. La JVM de Sun sólo asigna memoria, nunca se desasigna (hasta JVM muerte) cancela la asignación de memoria sólo después de una relación específica entre la memoria interna y necesidades de memoria asignada cae por debajo de un (ajustables) valor. La JVM se inicia con la cantidad especificada en-Xms y puede ser extendido hasta por el monto especificado en -Xmx. No estoy seguro de cuál de las configuraciones por defecto. Cuando la JVM necesita más memoria (nuevos objetos / primitivas / matrices) se asigna un fragmento de todo desde el sistema operativo. Sin embargo, cuando la necesidad se desploma (momentánea de la necesidad, véase 2) no cancela la asignación de la memoria de la OS de inmediato, pero se mantiene a sí mismo hasta que la relación se ha alcanzado. Una vez me dijeron que JRockit se comporta mejor, pero no puedo comprobarlo.

2. La JVM de Sun ejecuta un pleno de GC basa en varios factores desencadenantes. Uno de ellos es la cantidad de memoria disponible - cuando cae demasiado el JVM intenta realizar un completo GC para liberar a algunos más. Así que, cuando más que la memoria es asignada desde el sistema operativo (momentánea de la necesidad) la probabilidad de que un completo GC es baja. Esto significa que mientras que usted puede ver 30Mb de objetos "en vivo", no podría ser mucho más objetos "muertos" (no accesible), a la espera de una mesa a suceder. Sé yourkit tiene una gran vista llamados "muertos de los objetos", donde se pueden ver estas "sobras".

3. En "servidor", el modo, la JVM de Sun corre GC en modo paralelo (a diferencia de la mayor serie de "parar el mundo" GC). Esto significa que si bien puede ser de basura para recoger, podría no ser recogido inmediatamente por otros hilos de tomar todo el tiempo de CPU disponible. Va a ser recogidos antes de llegar fuera de la memoria (bueno, un poco. ver http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html), si más de la memoria pueden ser asignados por el sistema operativo, puede ser antes de la GC se ejecuta.

Combinado, una gran inicial configuración de la memoria y las explosiones cortas de la creación de una gran cantidad de objetos de corta duración podría crear un escenario como el descrito.

edit: cambiado "nunca deallcoates" a "sólo después de la relación alcanzado".

Exceso de hilo de la creación explica el problema a la perfección:

• Cada Hilo tiene su propia pila, que es independiente de la memoria heap y por lo tanto no registrados por los perfiladores
• El valor predeterminado de hilo tamaño de la pila es bastante grande, si mal no recuerdo 256KB (al menos lo fue para Java 1.3)
• La banda de rodadura de la pila de memoria probablemente no se vuelven a utilizar, por lo que si usted crear y destruir un montón de hilos, usted obtendrá un montón de fallos de página

Si alguna vez realmente necesita tener cientos de hilos aound, el hilo tamaño de la pila puede ser configurado a través de la -Xss parámetro de línea de comandos.

La recolección de basura es un lugar arcanos de la ciencia. Como el estado de la técnica se desarrolla, onu-tuned comportamiento va a cambiar en respuesta.

Java 6 se ha predeterminado diferente GC comportamiento y diferentes "ergonomía" a las anteriores versiones de JVM. Si le dices que se puede usar más memoria (ya sea de forma explícita en la línea de comandos, o implícitamente, al no especificar nada más explícito), se utilizará más memoria, si cree que se puede mejorar el rendimiento.

En este caso, Java 6 parece creer que reservar el espacio extra que la pila puede crecer en la voluntad de dar un mejor rendimiento, probablemente porque cree que esto hará más objetos a morir en Edén, en el espacio, y limitar el número de objetos promovido al puesto de profesor titular de la generación de espacio. Y a partir de las especificaciones de su hardware, la JVM no creo que este extra reservados montón de espacio causará ningún problema. Tenga en cuenta que muchos (aunque no todos) de los supuestos de la JVM hace para llegar a las conclusiones están basadas en la "típica" de las aplicaciones, en lugar de su aplicación específica. También hace que las suposiciones basadas en el hardware y el sistema operativo de perfil.

Si la JVM ha hecho cosas equivocadas, puede influir en su comportamiento a través de la línea de comandos, aunque es fácil de hacer las cosas mal...

La información acerca de los cambios de rendimiento en java 6 se puede encontrar aquí.

Hay una discusión sobre la gestión de la memoria y el rendimiento de sus implicaciones en la Gestión de la Memoria de Papel Blanco.