How I Diagnosed and Fixed a Java Process’s CPU Spike with jstack

1. Background

During development we logged into the OSS pre‑release console and noticed that a Java process was consuming an unusually high amount of CPU, which was unexpected for a machine used only for internal development and product testing.

2. Investigation

First, we ran top -Hp 15057 to view thread‑level CPU usage. The screenshot shows that thread 15393 was responsible for most of the CPU time, so we focused on that thread.

We converted the thread ID to hexadecimal with printf "%x\n" 15393, obtaining 0x3c21.

Next, we executed sudo -u www jstack 15057 to dump the stack traces of all threads in the process. By matching the hexadecimal ID 0x3c21, we identified the stack belonging to the CPU‑intensive thread.

The stack trace pointed to line 255 in LoguUtil. That line contains a loop that calls poll() on a blocking queue. Because poll() returns null when the queue is empty instead of blocking, the loop became a tight, non‑terminating loop.

The issue was not caught during testing because logs usually prevent execution from reaching line 255; we discovered it only when logging in late at night when no logs were generated.

3. Verification

After fixing the code and redeploying, we checked the CPU usage again and confirmed that the Java process returned to normal levels.

4. Summary

Beyond functional testing, developers should also monitor performance impact and address problems promptly.