Si no podés usar VisualVM ni JMX remoto, la estrategia correcta es:
CLI + correlación de datos
1. Encontrar el proceso
jps -l
o directamente:
ps aux | grep java
guardate el PID
2. Confirmar que el problema es CPU
top -p <pid>
o mejor:
top -H -p <pid>
Esto muestra threads individuales
Acá está la clave:
- Vas a ver un thread con CPU alto (ej: 200%)
- Anotá el TID (thread id)
3. Convertir TID a HEX (clave para Java)
Java muestra threads en hexadecimal, Linux en decimal.
printf "%x\n" <tid>
Ejemplo:
12345 → 3039
4.Sacar thread dump
jstack <pid> > dump.txt
5. Buscar el thread problemático
Dentro del dump:
grep -i 3039 dump.txt
Ese es el thread que está consumiendo CPU
¿Qué vas a encontrar? Generalmente algo así:
"id=123 nid=0x3039 runnable"
Y abajo el stack:
at com.miapp.CalculoPesado.procesar(CalculoPesado.java:42)
at com.miapp.Service.loop(Service.java:88)
¡encontraste el problema!
¿Dónde entra jstat en todo esto?
Acá es donde sumás contexto.
Ejecutá:
jstat -gcutil <pid> 1000
Qué mirar para CPU alto
Caso 1: GC excesivo
- YGC sube MUY rápido
- GCT crece constantemente
CPU alto por Garbage Collector
Caso 2: Full GC frecuentes
- FGC aumenta
- FGCT alto
pausas pesadas → CPU + latencia
Caso 3: GC normal
- GC estable
- memoria OK
Entonces el problema es código, no GC
