Understanding CPU Usage Spikes in Java Applications: Causes, Diagnosis, and Best Practices

Questions (疑惑)

Will an infinite while loop cause CPU usage to soar?

Can frequent Young GC trigger high CPU usage?

Does a high number of threads guarantee high CPU usage?

Does high CPU usage imply a high thread count?

Can BLOCKED threads cause CPU spikes?

In a time‑sharing OS, does CPU usage reflect user (us) or system (sy) time?

Thoughts (思考)

CPU usage is calculated as CPU% = 1 - idleTime / sysTime * 100 , where idleTime is the time the CPU is idle and sysTime is the total time spent in user and kernel modes.

CPU usage is influenced by computationally intensive operations. In Java, typical CPU‑heavy activities include:

Frequent GC, especially when allocation rates exceed memory capacity, causing GC threads to run continuously.

Serialization/deserialization (e.g., XML parsing) under high load.

Encryption and decryption.

Regular‑expression matching, which may backtrack heavily.

Thread context switches when many threads are blocked or competing for locks.

Busy‑wait loops such as while(true){/* computation */} without yielding.

Relationship between CPU, processes, and threads (CPU 与进程、线程的关系)

Modern time‑sharing operating systems allocate CPU time slices to processes; blocked processes do not consume CPU. Threads share the same process resources, and the JVM schedules them using either time‑slice or preemptive strategies.

Answers (解惑)

Infinite while loop : Yes, it continuously requests CPU time slices, preventing the thread from yielding, which drives CPU usage up.

Frequent Young GC : Yes, each GC cycle consumes CPU cycles for memory scanning and object relocation.

High thread count → high CPU? : No. Many threads can be in BLOCKED or WAITING states, contributing little to CPU load.

High CPU → high thread count? : No. A single compute‑intensive thread can saturate the CPU regardless of total thread count.

BLOCKED threads and CPU spikes : Not necessarily; CPU spikes are usually caused by runnable threads or context‑switch overhead.

us vs. sy in top : us represents user‑space CPU usage (application code), while sy represents kernel‑space usage (system calls, context switches).

Practical Experience (经验)

When CPU usage spikes, first check thread count, JVM metrics, and system load. Capture a jstack dump and analyze thread states, preferably with tools like fastThread . A real incident showed 100% CPU caused by XML deserialization of MQ messages; the heavy parsing saturated the CPU.

Author Bio

JD.com Marketplace Architecture Engineer with extensive experience building high‑performance, highly available large‑scale distributed systems. Joined JD in 2015 and currently leads system development for the service marketplace.