Understanding CPU Usage Spikes in Java Applications: Causes, Diagnosis, and Real‑World Example

Questions

Six common questions about CPU usage are presented: (1) Does an infinite while loop cause CPU usage to soar? (2) Can frequent Young GC raise CPU usage? (3) Do applications with many threads usually have higher CPU usage? (4) Is a large thread count a sign of high CPU usage? (5) Do BLOCKED threads increase CPU usage? (6) In a time‑sharing OS, does a high us or sy value indicate what?

Approach

1. How to calculate CPU usage?

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.

2. What operations are related to CPU usage?

Typical CPU‑intensive operations in Java include frequent GC, serialization/deserialization (e.g., XML parsing), regular‑expression processing, and thread‑context switching, especially when many threads execute busy loops such as while(true).

3. Is CPU usage tied to processes and threads?

In a time‑sharing OS, only threads in RUNNABLE state consume CPU; BLOCKED or WAITING threads do not. Java threads are lightweight processes that share process resources, and the JVM schedules them using either time‑sharing or pre‑emptive scheduling.

Answers

1. Infinite while loop

Yes. An infinite loop continuously requests CPU time slices and never yields, so the CPU remains occupied until the scheduler forces a context switch.

2. Frequent Young GC

Yes. Young GC is a JVM memory‑management operation that requires CPU cycles; frequent collections therefore increase CPU load.

3. Many threads

Not necessarily. If most threads are BLOCKED or WAITING, CPU usage can stay low even with thousands of threads. High CPU occurs when many threads are runnable and competing for CPU time.

4. High CPU implies many threads?

No. High CPU is usually driven by compute‑intensive work rather than thread count; a single thread performing heavy calculations can saturate the CPU.

5. BLOCKED threads

BLOCKED threads do not cause CPU spikes; spikes are typically caused by context switches and a large number of runnable threads.

6. High us vs sy values

us

represents the percentage of CPU time spent in user space (program code). A high us indicates that the application itself is consuming CPU. sy represents kernel‑space CPU usage; a high sy often points to kernel activity such as system calls or thread context switches.

Experience

When CPU usage is unusually high, first examine thread count, JVM metrics, and system load. Use tools like jstack or online analyzers (e.g., fastThread) to inspect thread stacks and identify hot spots.

Real‑world case: An alert showed 100% CPU usage. By exporting the thread dump with jstack and analyzing the stack trace, the culprit was identified as a method that deserialized MQ messages, which caused excessive CPU consumption.

Below is a snippet of the problematic stack trace (code kept intact):

onsumer_ODC_L_nn_jmq919_1543834242875 - priority:10- threadid:0x00007fbf7011e000- nativeid:0x2f093- state:RUNNABLE
stackTrace:
java.lang.Thread.State:RUNNABLE
at java.lang.Object.hashCode(NativeMethod)
at java.util.HashMap.hash(HashMap.java:362)
at java.util.HashMap.getEntry(HashMap.java:462)
at java.util.HashMap.containsKey(HashMap.java:449)
at com.project.order.odc.util.XmlSerializableTool.deSerializeXML(XMLSerializableTool.java:100)
at com.project.plugin.service.message.resolver.impl.OrderFinishMessageResolver.parseMessage(OrderFinishMessageResolver.java:55)
...

After locating the deserialization logic, the code was optimized, and CPU usage returned to normal.