Post La ergonomía JSE 5 está destinada a seleccionar automáticamente el tipo de recolector de basura adecuado para usted (entre otras cosas).encuentre qué tipo de recolector de basura se está ejecutando
Me gustaría saber si hay alguna forma de confirmar/conocer el tipo de recolector de basura y los objetivos de rendimiento elegidos/actuales establecidos por la ergonomía JVM.
Puede utilizar la bandera -XX para JRE para elegir el recolector de basura que desee.
Tuning Garbage Collection with the 5.0 Java TM Virtual Machine
Además, puede utilizar JConsole para controlar la recolección de basura.
Sé que puede elegir su recolector de basura, sin embargo, lo que me interesa es averiguar qué recopilador eligió la JVM para mí; quién sabe, ¡tal vez incluso podría cambiar las estrategias sobre la marcha en función del uso! –
@ ryan-fernandes de [Garbage Collector Ergonomics] (http://download.oracle.com/javase/1.5.0/docs/guide/vm/gc-ergonomics.html), en máquinas de clase servidor que ejecutan el servidor VM , el GC por defecto es colector paralelo, sino coleccionista en serie. – Garbage
Utilice GarbageCollectorMXBean s para obtener MemoryPoolMXBean s.
Bueno, esto realmente no le da el GC que está en uso. Curiosamente, sin embargo, la salida 'getVMOption' para UseSerialGC, UseParallelOldGC, UseParallelGC, UseConcMarkSweepGC, todos informan 'falso'. –
Disculpa, debería haberlo intentado antes de publicarlo :-(. Pensaba que lo había usado en el pasado para esto ... –
Esto debería darte los GC que pueden funcionar contra la JVM, viendo los atributos de collectionCount que puedes ver si están siendo utilizados. –
No es una respuesta directa a su pregunta, pero creo que esto es lo que está buscando.
Según Java 6 documentación 1 y 2 (no sólo de Java 5):
Referencia 1 dice:
En las máquinas de tipo servidor que ejecuta el servidor de VM, el recolector de basura (GC) ha cambiado desde el colector de serie anterior [...] a un colector paralelo
Referencia 2 dice:
A partir de J2SE 5.0, cuando una aplicación se pone en marcha, el lanzador puede intentar detectar si la aplicación se está ejecutando en una máquina "de tipo servidor" y, en caso por lo tanto, use la Máquina virtual Java HotSpot Server (máquina virtual del servidor) en lugar de la máquina virtual del cliente Java HotSpot (máquina virtual del cliente).
Además, la referencia 2 dice:
Nota: Para Java SE 6, la definición de una máquina de tipo servidor es uno con al menos 2 CPUs y al menos 2 GB de memoria física .
De esta información, puede saber que si la caja es un servidor (de acuerdo con 2), entonces usará el GC paralelo. También puede inferir que no cambiará GC durante el tiempo de ejecución.
Probablemente pueda encontrar la respuesta correcta para máquinas que no sean servidores si profundiza en la documentación.
exactamente! pero has probado esto en una máquina virtual? alguna idea de lo que podría pasar si asignase 1.75 núcleos a una instancia? –
No lo hice, pero mi tercera cita dice "al menos 2 CPUs" "así que supongo que usará el GC serial".Con respecto a su comentario "quería verlo en acción, antes de crear recomendaciones para la producción", la recomendación es siempre configurar el GC manualmente. –
Aquí hay información sobre cómo programar programáticamente la información del GC, pero parece que puede necesitar el nombre del GC de antemano. Molesto.
http://blogs.oracle.com/poonam/entry/how_to_programmatically_obtain_gc
Editar: tratar ManagementFactory.getGarbageCollectorMXBeans() y recorrer la lista devuelta. Uno de estos estará activo.
gracias !. pero lo intenté ... ver la respuesta de bkail (y comentarios) –
Ohh, acabo de darme cuenta. Whoops :) –
java -XX:+PrintCommandLineFlags -version
le mostrará el recolector de basura predeterminado. También encontré útil la siguiente página que detalla el recolector de basura predeterminado para varios sistemas operativos.
import java.lang.management.GarbageCollectorMXBean;
import java.lang.management.ManagementFactory;
import java.util.List;
public class GCInformation {
public static void main(String[] args) {
try {
List<GarbageCollectorMXBean> gcMxBeans = ManagementFactory.getGarbageCollectorMXBeans();
for (GarbageCollectorMXBean gcMxBean : gcMxBeans) {
System.out.println(gcMxBean.getName());
System.out.println(gcMxBean.getObjectName());
}
} catch (RuntimeException re) {
throw re;
} catch (Exception exp) {
throw new RuntimeException(exp);
}
}
}
por ejemplo tratar comandos siguientes para conocer diversos tipos de GC
java -XX:+PrintCommandLineFlags GCInformation
java -XX:+PrintCommandLineFlags -XX:+UseParallelGC GCInformation
java -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC GCInformation
java -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:-UseParNewGC GCInformation
Nota gcMxBean.getObjectName() solo funciona en JDK 7 en adelante –
-XX:+PrintGC
-XX:+PrintGCDetails
Esto imprimirá lo que se utiliza GC. En mi caso se imprime:
[GC (Allocation Failure) [PSYoungGen: 348192K->32K(348672K)] 356792K->8632K(1048064K), 0.0111518 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
Lo que significa que la basura paralelo colector está siendo utilizado para la generación joven. "Fallo de asignación" significa que la recolección de basura comenzó porque no había suficiente espacio en la parte del montón de la generación joven.
Esta impresión de comandos del tipo de GC de una JVM en ejecución:
jmap -heap <pid> | grep GC
Para la computadora moderna (varias CPU, memoria grande), JVM lo detectará como máquina servidor, y utilizar Parallel GC por defecto, a menos especifica qué gc usar a través de indicadores de JVM explícitamente.
por ejemplo
jmap -heap 26806 | grep GC
Salida:
GC paralelo con 8 hilo (s)
Soy curioso en cuanto a por qué quiere esta información. – casablanca
tenía curiosidad sobre la ergonomía, específicamente para GC y quería verlo en acción, antes de crear recomendaciones para la producción; intenté jvisualvm, sin alegría. –