grafica - jframe en java
¿Por qué un gráfico en forma de diente de sierra? (4)
Cualquier proceso que asigne objetos a una velocidad regular dará como resultado un aumento constante en el consumo de memoria del montón, seguido de caídas instantáneas cuando el recolector de basura recoja los objetos que ya no se utilizan, lo que resulta en esa forma de diente de sierra.
En caso de que se pregunte por qué su proceso java mantiene la memoria de asignación mientras escribe en System.out , tenga en cuenta que otros hilos (por ejemplo, el que alimenta las estadísticas de memoria actuales a JVisualVM) pueden ser los que asignan la memoria.
Cuando ejecuto el código mencionado a continuación usando NetBeans, el gráfico de tamaño de pila asignado se asemeja a una forma de diente de sierra. Estoy adjuntando la captura de pantalla de JVisualVM que muestra el gráfico de asignación de montón con una forma de diente de sierra. El programa es una simple impresión de bucle infinito "¡Hola mundo!" en la consola.
public class HelloWorld {
public static void main(String a[]){
while(true) {
System.out.println("Hello, World!");
}
}
}
¿Alguien puede explicar la razón detrás de la forma del gráfico del montón usado?
PD : Esto sucede incluso si lo ejecuto sin usar NetBeans, por lo que es muy probable que no esté relacionado con NetBeans ...
El patrón de diente de sierra en el uso del montón se puede explicar por el hecho de que se crean varias variables locales durante la invocación de la invocación System.out.println . En particular, en Oracle / Sun JRE, varias instancias de HeapCharBuffer se crean en la generación joven, como se indica en la siguiente instantánea obtenida con el generador de perfiles de memoria de VisualVM:
El bit interesante está en el número de objetos vivos que están presentes en el montón. El patrón de diente de sierra se debe al ciclo de recolección de basura de la generación joven que se produce cuando el espacio eden se llena; Como no se realiza una gran actividad computacional en el programa, la JVM es capaz de ejecutar varias iteraciones del bucle, lo que resulta en el llenado del espacio eden (de 4 MB en tamaño). El siguiente ciclo de recolección de la generación joven luego limpia la mayor parte de la basura; es casi siempre la totalidad del espacio eden, a menos que los objetos aún estén en uso, como lo indica la siguiente traza de gc obtenida de VisualVM:
Por lo tanto, el comportamiento del patrón de diente de sierra se puede explicar mediante una serie de asignaciones de objetos en rápida sucesión que llenan el espacio eden, lo que desencadena un ciclo de recolección de basura gen joven; este proceso se repite cíclicamente sin demoras, ya que el proceso JVM subyacente no es precedido por otro proceso, y el hilo principal dentro de la JVM que es responsable de las asignaciones de objetos tampoco es reemplazado por otro hilo.
En realidad jVisualVM causando la asignación de objetos adicionales. jVisualVM y jconsole están usando las extensiones de administración de Java. Se adjunta a la aplicación en ejecución y se solicitan métricas de JVM, lo que hace que se creen objetos adicionales. Puedes verificar esto agregando a tu programa la llamada a
Runtime.getRuntime().freeMemory()
que informa de memoria libre en el montón JVM. Se mostrará [casi] sin cambios de memoria ejecutando su código, pero tan pronto como conecte jVisualVM a su programa, verá un aumento en el uso de la memoria.
Hay muchos lugares de los que podría provenir, y es probable que dependa de la implementación. Al menos lo siguiente es posible (pero son simplemente especulaciones)
en algún lugar de la pila de flujos debajo de System.out.println hay una asignación de matriz de bytes (dado que uno de los métodos básicos de un flujo de salida es escritura (bytes [] b, int off, int len))
es una sobrecarga utilizada por el software de monitoreo que estás usando (no lo he usado)
es una sobrecarga en la máquina virtual netbeans donde termina mostrando la salida