Why Is My Java Service Slowing Down? Diagnose CPU Spikes, Full GC & Thread Issues

Processing online performance issues often reveals symptoms like sudden slowdown, CPU at 100%, and frequent Full GC, leading to alerts.

When a system becomes unresponsive, first export jstack and memory information, then restart to restore availability. Two main causes are large data reads causing memory exhaustion and CPU‑intensive operations.

Full GC overuse: identify via top showing high CPU, jstat showing many Full GC events, then locate the offending Java process (e.g., PID 9) and thread (e.g., thread id 10). Use jstack to see the stack, confirm GC threads (VM Thread), and disable explicit GC with -XX:+DisableExplicitGC.

High CPU: use top -Hp <pid> to find threads >80% CPU, map thread id to hex, inspect with jstack to differentiate between GC threads and application code.

Intermittent latency: stress test the endpoint, collect multiple jstack snapshots, compare to find threads that consistently appear in TIMED_WAITING state, then trace to blocking code (e.g., UserController line 34).

Thread stuck in WAITING: grep TIMED_WAITING threads across snapshots, isolate those that remain, and examine the stack to locate the waiting point (e.g., SyncTask lambda).

Deadlock: jstack reports deadlocked threads; locate the contended lock (e.g., ConnectTask line 5) and refactor to break the cycle.

Finally, a concise troubleshooting workflow is presented: use top to check CPU, jstat to monitor GC, jmap to dump the heap for MAT analysis, and jstack to inspect threads, applying the appropriate steps based on observed symptoms.