java - metodo - ¿GC vuelve a liberar memoria al sistema operativo?
qué es el garbagecollector (5)
Cuando el recolector de basura se ejecuta y libera memoria, esta memoria vuelve al sistema operativo o se mantiene como parte del proceso. Tenía la fuerte impresión de que la memoria nunca se vuelve a liberar al sistema operativo, sino que se mantiene como parte del área / grupo de memoria para ser reutilizada por el mismo proceso.
Como resultado, la memoria real de un proceso nunca disminuirá. Un artículo que me recordó fue esto y el tiempo de ejecución de Java está escrito en C / C ++, así que supongo que se aplica lo mismo.
Actualizar
Mi pregunta es sobre Java.
Menciono C / C ++ ya que supongo que la asignación / desasignación de Java la realiza JRE utilizando alguna forma de malloc / delete
El HotSpot JVM libera memoria al sistema operativo, pero lo hace de mala gana, ya que cambiar el tamaño del montón es costoso y se supone que si necesita ese montón una vez lo necesitará nuevamente.
Puede hacerlo más agresivo estableciendo
-XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30
que le permitirá dedicar más tiempo de CPU a recopilar y restringir la cantidad de memoria de montón asignada pero no utilizada después un ciclo de GC.
Suponiendo que está utilizando un recopilador concurrente, también puede establecer
-XX:InitiatingHeapOccupancyPercent=N
con N en un valor bajo para permitir que el GC ejecute colecciones concurrentes casi continuamente, lo que consumirá aún más ciclos de CPU pero reducirá el montón antes.
Esto
generalmente
no es una buena idea, pero en algunos tipos de máquinas con muchos núcleos de CPU de repuesto pero con poca memoria puede tener sentido.
Si está utilizando un recopilador con un objetivo de tiempo de pausa predeterminado (CMS o G1) también puede relajar ese objetivo para colocar menos restricciones en el recopilador, o puede cambiar al recopilador paralelo para priorizar la huella sobre los tiempos de pausa.
Además, con Java 9
-XX:-ShrinkHeapInSteps
opción
-XX:-ShrinkHeapInSteps
se puede utilizar para aplicar la reducción causada por las dos opciones anteriores de forma más agresiva.
Error relevante de OpenJDK
.
Tenga en cuenta que la capacidad y el comportamiento de reducción dependen del recolector de basura elegido.
Por ejemplo, G1 solo obtuvo la capacidad de
devolver fragmentos no utilizados en el medio del montón
con jdk8u20, mientras que ZGC lo
hizo con jdk13
y el recopilador epsilon probablemente nunca lo hará.
Por lo tanto, si se desea una reducción del almacenamiento dinámico, debe probarse para una versión JVM particular y una configuración GC.
El registro de GC con
PrintAdaptiveSizePolicy
también puede proporcionar información, por ejemplo, cuando la JVM intenta usar más memoria para que la generación joven cumpla algunos objetivos.
También hay
JEP 346
, incluido en OpenJDK 12, que introduce la liberación de memoria rápida para G1GC con la opción
G1PeriodicGCInterval
, nuevamente a expensas de alguna CPU adicional.
También menciona características similares en
Shenandoah
y
OpenJ9 VM
.
Este artículo explica cómo funciona el GC en Java 7. En pocas palabras, hay muchos recolectores de basura diferentes disponibles. Por lo general, la memoria se guarda para el proceso de Java y solo algunos GC la liberan al sistema (creo que a pedido). Pero, la memoria utilizada por el proceso Java no crecerá indefinidamente, ya que existe un límite superior definido por la opción Xmx (que suele ser de 256 m, pero creo que depende del sistema operativo / máquina).
La JVM libera memoria en algunas circunstancias, pero (por razones de rendimiento) esto no sucede cuando se recolecta algo de memoria. También depende de JVM, OS, recolector de basura, etc. Puede ver el consumo de memoria de su aplicación con JConsole, VisualVM u otro generador de perfiles.
Vea también este informe de error relacionado
Si usa el recopilador G1 y llama a System.gc () ocasionalmente (lo hago una vez por minuto), Java reducirá el montón de forma confiable y devolverá la memoria al sistema operativo.
Algunas personas hacen espuma en la boca cada vez que mencionas la idea de invocar manualmente al recolector de basura, pero debes hacerlo si quieres una compactación confiable.
Recomiendo usar estas opciones combinadas con la sugerencia anterior para un tamaño de proceso residente muy compacto:
-XX:+UseG1GC -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=10
He estado usando estas opciones diariamente durante meses con una gran aplicación (un sistema operativo invitado basado en Java) con clases de carga y descarga dinámicas, y el proceso Java casi siempre se mantiene entre 400 y 800 MB.
Editar: JDK 12 hará que el recopilador G1 devuelva la memoria al sistema operativo (sin llamar a System.gc) "cuando la aplicación esté inactiva". El último término parece estar definido para aplicaciones de servidor, pero tal vez también funcione para escritorio y / o lo hagan personalizable.