Step-by-Step Guide to Diagnose Java CPU Spikes and Full GC Issues

1. Introduction

CPU spikes are common in online services, especially during traffic bursts; following the steps below usually allows you to locate the problem within about one minute.

2. Problem Reproduction

The system becomes sluggish, CPU climbs to 100%, Full GC occurs repeatedly, and various alerts (e.g., interface timeout) are triggered, requiring rapid online diagnosis.

3. Investigation

Since the symptom is a CPU spike, first identify the threads that consume CPU and then examine GC activity.

3.1 Core Investigation Steps

Execute top to list all processes sorted by CPU usage; the Java process is usually the first entry (look at the COMMAND column). Record its PID.

Execute top -Hp <PID> to view CPU usage of each thread within the Java process.

Execute printf "%x\n" 10 to convert a decimal thread ID to hexadecimal (e.g., 10 → a), which matches the nid shown by jstack .

Execute jstack <PID> | grep <hex_thread_id> to locate the thread stack entry. If the line contains "VM Thread" it indicates a JVM GC thread.

Execute jstat -gcutil <PID> <interval_ms> <count> to monitor GC statistics; a continuously increasing FGC value confirms Full GC. You can also run jmap -heap <PID> to check heap usage, especially the old generation threshold.

Execute jmap -dump:format=b,file=<filename> <PID> to export the heap to a file for analysis with tools such as Eclipse MAT.

3.2 Cause Analysis

1. Excessive memory consumption leading to many Full GC cycles

Steps 1‑5 reveal that multiple threads exceed 100% CPU, mainly GC threads, and jstat shows a high and growing Full GC count.

Large object creation causing heap pressure – investigate with step 6.

Low memory usage but frequent Full GC may be caused by explicit System.gc() calls; disable with -XX:+DisableExplicitGC.

2. CPU‑intensive code (e.g., complex algorithms, infinite loops)

Use step 4 (jstack) to pinpoint the offending thread and locate the corresponding source line.

3. Improper lock usage resulting in deadlock

Deadlocks are reported by jstack with the keyword "deadlock" and show the locked threads; typical cause is two threads waiting on each other's locks.

4. Randomly slow interface due to blocking operations

A specific code segment may block, causing occasional latency spikes while overall CPU and memory remain low.

5. Threads stuck in WAITING state (e.g., CountDownLatch, AQS, LockSupport.park())

Run steps 1‑4 repeatedly (interval ~30 s) and compare thread states; a thread staying in WAITING indicates a blocking construct.

"http-nio-8080-exec-4" #31 daemon prio=5 os_prio=31 tid=0x00007fd08d0fa000 nid=0x6403 waiting on condition [0x0000700033db000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at java.lang.Thread.sleep(Thread.java:340)
    at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
    at com.*.user.controller.UserController.detail(UserController.java:18) // business code blocking point

"Thread-0" #11 prio=5 os_prio=31 tid=0x00007f9de08c7000 nid=0x5603 waiting on condition [0x000070001f89000]
java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
    at com.*.SyncTask.lambda$main$0(SyncTask.java:8) // business code blocking point
    at com.*.SyncTask$Lambda$1/1791741888.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:748)

4. Summary

By following the six steps in section 3.1 you can usually identify the root cause of a Java CPU spike and take appropriate remediation.