JVM GC 
WTF?! 
Alonso Torres @alotor
Alonso Torres 
@alotor @alotor 
mobro.co/alotor
java.lang.OutOfMemoryError: unable to create new native thread 
java.lang.OutOfMemoryError: Stack overflow 
java.lang.OutOfMemoryError: PermGen space 
java.lang.OutOfMemoryError: Metaspace 
java.lang.OutOfMemoryError: Java heap space 
java.lang.OutOfMemoryError: GC overhead limit exceeded 
java.lang.OutOfMemoryError: requested... Out of swap space?
SUCCESS
No tengo memoria!!! 
Todo va lento!!!!!! 
El GC es ineficiente!!!!!
With CMS GC, the full collection is serial and STW, 
hence your application threads are stopped for the 
entire duration while the heap space is reclaimed 
and then compacted. 
The duration for the STW pause depends on your 
heap size and the surviving objects. 
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
Con el recolector CMS, la recolección es “serie” y 
STW, y los hilos de tu aplicación serán detenidos 
por la duración completa mientras el espacio del 
“heap” es recuperado y compactado. 
La duración de la pausa STW dependerá del 
tamaño del “heap” y de los objetos supervivientes. 
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
JVM 
Java Virtual Machine 
GC 
Garbage Collectors 
WTF?! 
Why They Fail?!
1. Estructura de la memoria 
2. Conceptos generales de GC 
3. Tipos de recolectores de Hotspot 
4. Configuración de Hotspot
Os presento la 
JVM
JVM PROCESS: 1.591 Gb
JVM PROCESS: 1.591 Gb 
Memoria propia de la JVM
JVM PROCESS: 1.591 Gb 
Memoria de ejecución
JVM PROCESS: 1.591 Gb 
Memoria de datos
JVM PROCESS: 1.591 Gb 
Memoria de clases
HEAP 
- Bloque de memoria que la JVM se encargará de 
gestionar 
- Almacena los datos de los objetos 
- Memoria dinámica
OCUPADA LIBRE 
Max. Heap Size
OCUPADA LIBRE 
Max. Heap Size
OCUPADA LIBRE 
Max. Heap Size
OCUPADA LIBRE
OCUPADA LIBRE
AUMENTAMOS el heap 
ó 
LIBERAMOS memoria
OCUPADA LIBRE 
Aumenta el heap 
Liberamos el heap 
OCUPADA LIBRE
¿Cómo liberamos la memoria 
que ya no necesitamos?
Garbage Collection 
1. Busca todos los objetos vivos 
2. Libera la memoria de los objetos muertos 
3. Mueve la posición de memoria de los vivos
GC’s en OpenJDK Hotspot 
- Serial Collector 
- Parallel Collector 
- CMS Collector 
- G1
GC’s en OpenJDK Hotspot 
- Serial Collector 
- Parallel Collector 
- CMS Collector 
- G1
MALDITOS 
TÉRMINOS!!
Stop the World (STW) 
- Parada global de todos los hilos de ejecución para 
realizar recolección de basura 
- El contrario puede ser CONCURRENTE 
○ La recolección se ejecuta a la vez que el 
programa
STW Concurrente
Paralelo 
● La ejecución se realiza en varios hilos de ejecución 
● Aprovecha sistemas con múltiples CPUs 
● Por contra puede ser SERIE 
○ Sólo se ejecutaría en un hilo
Paralelo Serie
Incremental 
● El trabajo de recolección no se realiza en un único 
paso sino en varias fases o pasos 
● Por el contrario puede ser MONOLÍTICO 
○ Todo se ejecuta en un sólo paso
Incremental Monolítico
Weak Generational Hypothesis 
- La mayoría de los objetos mueren jóvenes 
- Los objetos viejos no suelen referenciar a objetos 
jóvenes
Generational GC 
Dos tipos de recolección: 
○ 1 espacio pequeño con muchos muertos 
○ 1 espacio grande donde casi todos vivos
Número de objetos vivos Número de objetos
TODOS 
los GC’s son generacionales
Generational heap structure 
YOUNG OLD/TENURE
Generational heap structure 
SURVIVORS 
SURVIVORS 
EDEN OLD/TENURE
Recolectamos la Young Generation 
Objetos promocionados van a supervivientes y a la 
Old Generation
La Old Generation está llena 
Necesitamos una recolección completa
Empty young and survivors. 
Free dead old-gen objects
GC’s en OpenJDK Hotspot 
● Serial Collector 
● Parallel Collector 
● CMS Collector 
● G1 (Garbage First) Collector
Serial Collector 
YOUNG GENERATION OLD GENERATION 
Serial 
Monolithic 
Stop-The-World 
Copying Mark / Sweep / Compact
Algoritmo de COPIA (Scavenge) 
- Copia los objetos vivos de una región de la 
memoria a otra 
- Libera la zona de memoria antigua
Mark / Sweep / Compact (MSC) 
1. Mark
Mark / Sweep / Compact (MSC) 
2. Sweep
Mark / Sweep / Compact (MSC) 
3. Compact
GC’s en OpenJDK Hotspot 
● Serial Collector 
● Parallel Collector 
● CMS Collector 
● G1 (Garbage First) Collector
Parallel Collector 
YOUNG GENERATION OLD GENERATION 
Paralelo Serie / Paralelo 
Monolítico 
Stop-The-World 
Copying Mark / Sweep / Compact
GC’s en OpenJDK Hotspot 
● Serial Collector 
● Parallel Collector 
● CMS Collector 
● G1 (Garbage First) Collector
Concurrent Mark & Sweep 
YOUNG GENERATION OLD GENERATION 
Paralelo Serie Y Paralelo 
Monolítico Incremental 
Stop-The-World STW Y Concurrente 
Copying Mark and Sweep
Concurrent Mark & Sweep 
1. Initial Mark 
2. Concurrent Mark 
3. Remark 
4. Concurrent Sweep
CMS 
No compacta
CMS después de varias generaciones
Cuando hay excesiva 
fragmentación 
STW,Serial, Monolithic, MSC* 
*AKA: Full GC
GC’s en OpenJDK Hotspot 
● Serial Collector 
● Parallel Collector 
● CMS Collector 
● G1 (Garbage First) Collector
Garbage First (G1) 
- Retrasar al máximo un “Full GC” 
- Baja latencia 
- Predictibilidad 
- Fácil de usar
Garbage First (G1) 
- Divide el heap en regiones 
- Libera primero las que tienen más basura 
(Garbage First) 
- Compacta sobre la marcha
E O 
O 
E 
O 
O 
O 
S 
G1 Heap Structure 
E
Garbage First (G1) 
1. Recolección de Young Collection 
2. Marcado concurrente 
3. Recolección mixta 
4. Full GC
Young collection 
E O 
O 
E E 
O 
O 
O 
E
Young collection 
O 
O 
O 
O 
O 
S
Garbage First (G1) 
1. Recolección de Young Collection 
2. Marcado concurrente 
3. Recolección mixta 
4. Full GC
Marcado concurrente 
E O 
O 
O 
O 
O 
E 
E O 
S 
O O
Marcado concurrente 
E O 
O 
E 
X 
O 
X 
O 
O O 
O
Garbage First (G1) 
1. Recolección de Young Collection 
2. Marcado concurrente 
3. Recolección mixta 
4. Full GC
Recolección mixta 
E O 
O 
E 
E X 
O 
X 
E 
O 
O O 
O 
O 
O 
O 
O
Recolección mixta 
E O 
O 
E 
E X 
O 
X 
E 
O 
O O 
O 
O 
O 
O 
O
Recolección mixta 
O 
O 
O 
X 
O 
O O 
O 
O 
O 
O 
S O
Garbage First (G1) 
1. Recolección de Young Collection 
2. Marcado concurrente 
3. Recolección mixta 
4. Full GC
Todos los GC’s de Hotspot 
tienen algún tipo de STW
STW 
es el mayor enemigo 
del rendimiento
Objetivos de optimización 
1. Maximizar recolección JOVEN 
2. Minimizar los STW 
3. Evitar objetos grandes 
4. Evitar retención de objetos
Monitorizar la aplicación
Opciones de monitorización 
-Xloggc:<file> 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps
[GC [PSYoungGen: 578424K->8793K(630784K)] 
1007570K->444386K(1155072K), 0.0185270 secs] 
[Times: user=0.06 sys=0.00, real=0.02 secs] 
[GC [PSYoungGen: 580697K->15128K(636928K)] 
1016290K->459169K(1161216K), 0.0236090 secs] 
[Times: user=0.08 sys=0.01, real=0.02 secs] 
[GC [PSYoungGen: 450179K->6893K(635904K)] 
894221K->465458K(1160192K), 0.0249430 secs] 
[Times: user=0.07 sys=0.02, real=0.02 secs] 
[Full GC [PSYoungGen: 6893K->0K(635904K)] 
[ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K) 
[PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs] 
[Times: user=8.48 sys=0.01, real=2.53 secs]
[GC [PSYoungGen: 578424K->8793K(630784K)] 
1007570K->444386K(1155072K), 0.0185270 secs] 
[Times: user=0.06 sys=0.00, real=0.02 secs] 
[GC [PSYoungGen: 580697K->15128K(636928K)] 
1016290K->459169K(1161216K), 0.0236090 secs] 
[Times: user=0.08 sys=0.01, real=0.02 secs] 
[GC [PSYoungGen: 450179K->6893K(635904K)] 
894221K->465458K(1160192K), 0.0249430 secs] 
[Times: user=0.07 sys=0.02, real=0.02 secs] 
[Full GC [PSYoungGen: 6893K->0K(635904K)] 
Recolección Young Generation 
[ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K) 
[PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs] 
[Times: user=8.48 sys=0.01, real=2.53 secs] 
Full GC (STW)
YOUNG SURVIVORS OLD 
Resumen del total
Análisis en detalle
Herramientas 
jcmd pid GC.class_histogram
num #instances #bytes class name 
---------------------------------------------- 
1: 762525 71798392 [C 
2: 41739 68376080 [B 
3: 675097 54007760 java.lang.reflect.Method 
4: 404377 51770560 <methodKlass> 
5: 404377 49495808 <constMethodKlass> 
6: 864167 48393352 org.codehaus.groovy.runtime.metaclass. 
7: 17110 29966392 <constantPoolKlass> 
8: 710424 22733568 java.util.HashMap$Entry 
9: 13777 18368640 <constantPoolCacheKlass> 
10: 760859 18260616 java.lang.String 
11: 507462 15419000 [Ljava.lang.Object; 
12: 17104 14833688 <instanceKlassKlass> 
13: 85375 12536048 [Lorg.codehaus.groovy.util.ComplexKeyHashMap$En 
14: 303170 9701440 org.codehaus.groovy.util.SingleKeyHashMap$Entry 
15: 386458 9274992 org.codehaus.groovy.util.FastArray 
16: 50174 8596088 [Ljava.util.HashMap$Entry; 
17: 333114 7010016 [Ljava.lang.Class;
Herramientas 
jcmd pid GC.class_histogram 
jcmd pid GC.heap_dump filename 
+ 
jhat heapdumpfile
Herramientas 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=path
Configurar la JVM
Configuraciones 
-Xmx / -Xms 
Tamaño máximo y mínimo del HEAP 
-XX:MaxGCPauseMillis=n 
Recomendación de pausas 
-XX:SurvivorRatio=n 
Tamaño del espacio de supervivientes
Tantas como para 
otra charla ;)
1. Estructura de la memoria 
2. Conceptos generales de GC 
3. Tipos de recolectores de Hotspot 
4. Configuración de Hotspot
Con el recolector CMS, la recolección es “serie” y 
STW, y los hilos de tu aplicación serán detenidos 
por la duración completa mientras el espacio del 
“heap” es recuperado y compactado. 
La duración de la pausa STW dependerá del 
tamaño del “heap” y de los objetos supervivientes. 
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
No es tan fiero el lobo 
como lo pintan
Alonso Torres 
@alotor @alotor 
mobro.co/alotor
Bonus (post-presentación) 
- Alternativas a JConsole 
○ VisualVM 
○ AppDynamics 
- Para medir paradas del GC 
○ JHiccup http://www.azulsystems.com/product/jHiccup 
○ JMeter

(Codemotion 2014) JVM GC: WTF?!

  • 1.
    JVM GC WTF?! Alonso Torres @alotor
  • 2.
    Alonso Torres @alotor@alotor mobro.co/alotor
  • 4.
    java.lang.OutOfMemoryError: unable tocreate new native thread java.lang.OutOfMemoryError: Stack overflow java.lang.OutOfMemoryError: PermGen space java.lang.OutOfMemoryError: Metaspace java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: requested... Out of swap space?
  • 6.
  • 7.
    No tengo memoria!!! Todo va lento!!!!!! El GC es ineficiente!!!!!
  • 8.
    With CMS GC,the full collection is serial and STW, hence your application threads are stopped for the entire duration while the heap space is reclaimed and then compacted. The duration for the STW pause depends on your heap size and the surviving objects. http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
  • 9.
    Con el recolectorCMS, la recolección es “serie” y STW, y los hilos de tu aplicación serán detenidos por la duración completa mientras el espacio del “heap” es recuperado y compactado. La duración de la pausa STW dependerá del tamaño del “heap” y de los objetos supervivientes. http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
  • 11.
    JVM Java VirtualMachine GC Garbage Collectors WTF?! Why They Fail?!
  • 12.
    1. Estructura dela memoria 2. Conceptos generales de GC 3. Tipos de recolectores de Hotspot 4. Configuración de Hotspot
  • 13.
  • 14.
  • 15.
    JVM PROCESS: 1.591Gb Memoria propia de la JVM
  • 16.
    JVM PROCESS: 1.591Gb Memoria de ejecución
  • 17.
    JVM PROCESS: 1.591Gb Memoria de datos
  • 18.
    JVM PROCESS: 1.591Gb Memoria de clases
  • 19.
    HEAP - Bloquede memoria que la JVM se encargará de gestionar - Almacena los datos de los objetos - Memoria dinámica
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
    AUMENTAMOS el heap ó LIBERAMOS memoria
  • 26.
    OCUPADA LIBRE Aumentael heap Liberamos el heap OCUPADA LIBRE
  • 27.
    ¿Cómo liberamos lamemoria que ya no necesitamos?
  • 28.
    Garbage Collection 1.Busca todos los objetos vivos 2. Libera la memoria de los objetos muertos 3. Mueve la posición de memoria de los vivos
  • 29.
    GC’s en OpenJDKHotspot - Serial Collector - Parallel Collector - CMS Collector - G1
  • 30.
    GC’s en OpenJDKHotspot - Serial Collector - Parallel Collector - CMS Collector - G1
  • 31.
  • 32.
    Stop the World(STW) - Parada global de todos los hilos de ejecución para realizar recolección de basura - El contrario puede ser CONCURRENTE ○ La recolección se ejecuta a la vez que el programa
  • 33.
  • 34.
    Paralelo ● Laejecución se realiza en varios hilos de ejecución ● Aprovecha sistemas con múltiples CPUs ● Por contra puede ser SERIE ○ Sólo se ejecutaría en un hilo
  • 35.
  • 36.
    Incremental ● Eltrabajo de recolección no se realiza en un único paso sino en varias fases o pasos ● Por el contrario puede ser MONOLÍTICO ○ Todo se ejecuta en un sólo paso
  • 37.
  • 38.
    Weak Generational Hypothesis - La mayoría de los objetos mueren jóvenes - Los objetos viejos no suelen referenciar a objetos jóvenes
  • 39.
    Generational GC Dostipos de recolección: ○ 1 espacio pequeño con muchos muertos ○ 1 espacio grande donde casi todos vivos
  • 40.
    Número de objetosvivos Número de objetos
  • 41.
    TODOS los GC’sson generacionales
  • 42.
    Generational heap structure YOUNG OLD/TENURE
  • 43.
    Generational heap structure SURVIVORS SURVIVORS EDEN OLD/TENURE
  • 46.
    Recolectamos la YoungGeneration Objetos promocionados van a supervivientes y a la Old Generation
  • 48.
    La Old Generationestá llena Necesitamos una recolección completa
  • 49.
    Empty young andsurvivors. Free dead old-gen objects
  • 50.
    GC’s en OpenJDKHotspot ● Serial Collector ● Parallel Collector ● CMS Collector ● G1 (Garbage First) Collector
  • 51.
    Serial Collector YOUNGGENERATION OLD GENERATION Serial Monolithic Stop-The-World Copying Mark / Sweep / Compact
  • 52.
    Algoritmo de COPIA(Scavenge) - Copia los objetos vivos de una región de la memoria a otra - Libera la zona de memoria antigua
  • 53.
    Mark / Sweep/ Compact (MSC) 1. Mark
  • 54.
    Mark / Sweep/ Compact (MSC) 2. Sweep
  • 55.
    Mark / Sweep/ Compact (MSC) 3. Compact
  • 56.
    GC’s en OpenJDKHotspot ● Serial Collector ● Parallel Collector ● CMS Collector ● G1 (Garbage First) Collector
  • 57.
    Parallel Collector YOUNGGENERATION OLD GENERATION Paralelo Serie / Paralelo Monolítico Stop-The-World Copying Mark / Sweep / Compact
  • 58.
    GC’s en OpenJDKHotspot ● Serial Collector ● Parallel Collector ● CMS Collector ● G1 (Garbage First) Collector
  • 59.
    Concurrent Mark &Sweep YOUNG GENERATION OLD GENERATION Paralelo Serie Y Paralelo Monolítico Incremental Stop-The-World STW Y Concurrente Copying Mark and Sweep
  • 60.
    Concurrent Mark &Sweep 1. Initial Mark 2. Concurrent Mark 3. Remark 4. Concurrent Sweep
  • 61.
  • 62.
    CMS después devarias generaciones
  • 63.
    Cuando hay excesiva fragmentación STW,Serial, Monolithic, MSC* *AKA: Full GC
  • 64.
    GC’s en OpenJDKHotspot ● Serial Collector ● Parallel Collector ● CMS Collector ● G1 (Garbage First) Collector
  • 65.
    Garbage First (G1) - Retrasar al máximo un “Full GC” - Baja latencia - Predictibilidad - Fácil de usar
  • 66.
    Garbage First (G1) - Divide el heap en regiones - Libera primero las que tienen más basura (Garbage First) - Compacta sobre la marcha
  • 67.
    E O O E O O O S G1 Heap Structure E
  • 68.
    Garbage First (G1) 1. Recolección de Young Collection 2. Marcado concurrente 3. Recolección mixta 4. Full GC
  • 69.
    Young collection EO O E E O O O E
  • 70.
  • 71.
    Garbage First (G1) 1. Recolección de Young Collection 2. Marcado concurrente 3. Recolección mixta 4. Full GC
  • 72.
    Marcado concurrente EO O O O O E E O S O O
  • 73.
    Marcado concurrente EO O E X O X O O O O
  • 74.
    Garbage First (G1) 1. Recolección de Young Collection 2. Marcado concurrente 3. Recolección mixta 4. Full GC
  • 75.
    Recolección mixta EO O E E X O X E O O O O O O O O
  • 76.
    Recolección mixta EO O E E X O X E O O O O O O O O
  • 77.
    Recolección mixta O O O X O O O O O O O S O
  • 78.
    Garbage First (G1) 1. Recolección de Young Collection 2. Marcado concurrente 3. Recolección mixta 4. Full GC
  • 79.
    Todos los GC’sde Hotspot tienen algún tipo de STW
  • 80.
    STW es elmayor enemigo del rendimiento
  • 81.
    Objetivos de optimización 1. Maximizar recolección JOVEN 2. Minimizar los STW 3. Evitar objetos grandes 4. Evitar retención de objetos
  • 82.
  • 83.
    Opciones de monitorización -Xloggc:<file> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
  • 84.
    [GC [PSYoungGen: 578424K->8793K(630784K)] 1007570K->444386K(1155072K), 0.0185270 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] [GC [PSYoungGen: 580697K->15128K(636928K)] 1016290K->459169K(1161216K), 0.0236090 secs] [Times: user=0.08 sys=0.01, real=0.02 secs] [GC [PSYoungGen: 450179K->6893K(635904K)] 894221K->465458K(1160192K), 0.0249430 secs] [Times: user=0.07 sys=0.02, real=0.02 secs] [Full GC [PSYoungGen: 6893K->0K(635904K)] [ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K) [PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs] [Times: user=8.48 sys=0.01, real=2.53 secs]
  • 85.
    [GC [PSYoungGen: 578424K->8793K(630784K)] 1007570K->444386K(1155072K), 0.0185270 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] [GC [PSYoungGen: 580697K->15128K(636928K)] 1016290K->459169K(1161216K), 0.0236090 secs] [Times: user=0.08 sys=0.01, real=0.02 secs] [GC [PSYoungGen: 450179K->6893K(635904K)] 894221K->465458K(1160192K), 0.0249430 secs] [Times: user=0.07 sys=0.02, real=0.02 secs] [Full GC [PSYoungGen: 6893K->0K(635904K)] Recolección Young Generation [ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K) [PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs] [Times: user=8.48 sys=0.01, real=2.53 secs] Full GC (STW)
  • 87.
    YOUNG SURVIVORS OLD Resumen del total
  • 88.
  • 89.
    Herramientas jcmd pidGC.class_histogram
  • 90.
    num #instances #bytesclass name ---------------------------------------------- 1: 762525 71798392 [C 2: 41739 68376080 [B 3: 675097 54007760 java.lang.reflect.Method 4: 404377 51770560 <methodKlass> 5: 404377 49495808 <constMethodKlass> 6: 864167 48393352 org.codehaus.groovy.runtime.metaclass. 7: 17110 29966392 <constantPoolKlass> 8: 710424 22733568 java.util.HashMap$Entry 9: 13777 18368640 <constantPoolCacheKlass> 10: 760859 18260616 java.lang.String 11: 507462 15419000 [Ljava.lang.Object; 12: 17104 14833688 <instanceKlassKlass> 13: 85375 12536048 [Lorg.codehaus.groovy.util.ComplexKeyHashMap$En 14: 303170 9701440 org.codehaus.groovy.util.SingleKeyHashMap$Entry 15: 386458 9274992 org.codehaus.groovy.util.FastArray 16: 50174 8596088 [Ljava.util.HashMap$Entry; 17: 333114 7010016 [Ljava.lang.Class;
  • 91.
    Herramientas jcmd pidGC.class_histogram jcmd pid GC.heap_dump filename + jhat heapdumpfile
  • 93.
  • 94.
  • 95.
    Configuraciones -Xmx /-Xms Tamaño máximo y mínimo del HEAP -XX:MaxGCPauseMillis=n Recomendación de pausas -XX:SurvivorRatio=n Tamaño del espacio de supervivientes
  • 96.
    Tantas como para otra charla ;)
  • 98.
    1. Estructura dela memoria 2. Conceptos generales de GC 3. Tipos de recolectores de Hotspot 4. Configuración de Hotspot
  • 99.
    Con el recolectorCMS, la recolección es “serie” y STW, y los hilos de tu aplicación serán detenidos por la duración completa mientras el espacio del “heap” es recuperado y compactado. La duración de la pausa STW dependerá del tamaño del “heap” y de los objetos supervivientes. http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
  • 100.
    No es tanfiero el lobo como lo pintan
  • 101.
    Alonso Torres @alotor@alotor mobro.co/alotor
  • 102.
    Bonus (post-presentación) -Alternativas a JConsole ○ VisualVM ○ AppDynamics - Para medir paradas del GC ○ JHiccup http://www.azulsystems.com/product/jHiccup ○ JMeter