Diagnosing CPU Spikes in Java Applications

When CPU spikes in a Java application, the most important thing is to capture data before restarting — a restart clears the evidence and you're left guessing.

Capture a flamegraph during the spike

• ./profiler.sh -d 30 -f spike.html PID captures a 30-second CPU flamegraph while the spike is happening — the widest boxes at the top of the flamegraph are the methods consuming the most CPU during the spike
• async-profiler doesn't require the application to be stopped or restarted; it's safe to run in production briefly

Common causes visible in flamegraphs

• GC pressure: the flamegraph shows the GC threads consuming a large fraction of CPU — confirm with jstat -gcutil PID 1000 which shows GC pauses and heap usage in real time; if Old Gen usage is climbing toward 100%, a full GC is imminent
• Hot locks: many threads piling up on a synchronized block or ReentrantLock; the flamegraph shows all threads in the same lock-acquire call path; a jstack PID at the same time shows threads in BLOCKED state
• Compilation: the JVM's JIT compiler compiles hot methods; a cold-start CPU spike often shows Interpreter and CompilerThread frames; this is expected and subsides as the JVM warms up
• Regex compilation: Pattern.compile() in a hot path is CPU-intensive; compile patterns at class initialization and store as static final fields

GC-related CPU spikes

• Young GC pauses are frequent but short (< 50ms); high young GC frequency means the application is allocating objects faster than the young gen can be collected; increase Eden size or reduce allocations
• Old Gen full GC is the severe case — jstat -gcutil PID shows O column approaching 100% before the spike; the full GC pause causes a CPU spike as all application threads stop; look for memory leaks or over-caching