Using Arthas to Diagnose High CPU Issues in a Java Application

Arthas is an open‑source Java diagnostic tool from Alibaba that provides a more user‑friendly and powerful alternative to the built‑in JDK tools, allowing one‑click problem location, class decompilation, and even hot code replacement in production.

First, download and start Arthas:

curl -O https://alibaba.github.io/arthas/arthas-boot.jar
java -jar arthas-boot.jar

After launching, select the target JVM process; the tool attaches successfully and shows information such as version, home directory, and connection details.

[INFO] arthas-boot version: 3.1.7
[INFO] Found existing java process, please choose one and hit RETURN.
* [1]: 12707
  [2]: 30724 org.jetbrains.jps.cmdline.Launcher
  [3]: 30725 org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication
  ...
3
[INFO] arthas home: /Users/zhuye/.arthas/lib/3.1.7/arthas
[INFO] Try to attach process 30725
[INFO] Attach process 30725 success.
[INFO] arthas-client connect 127.0.0.1 3658

Running the help command reveals many commands; for this case we use dashboard , thread , jad , watch and ognl to investigate the HighCPUApplication process.

The dashboard command shows overall thread, memory, and GC status. It reveals that the high CPU is not caused by GC; eight threads consume most CPU, seven of which belong to ForkJoinPool.commonPool , indicating the issue lies in parallel‑stream code.

Next, the thread -n 8 command lists the eight busiest threads. The output shows they are all executing MD5 operations, consuming a large amount of CPU.

thread -n 8

Since the main thread also participates in the ForkJoinPool tasks, its stack points to the doTask method of org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication . We decompile the class with jad :

jad org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication

The decompiled code shows that when the integer parameter of doTask equals a certain constant, the method performs 10,000 MD5 calculations, which is the CPU hotspot. The constant turns out to be the value of User.ADMIN_ID .

To confirm the parameter value, we use the watch command to monitor doTask calls whose execution time exceeds 100 ms and print the parameters (expanded two levels):

watch org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication doTask '{params}' '#cost>100' -x 2

The watch output shows that all slow doTask invocations have the parameter value 0 , suggesting that User.ADMIN_ID is 0 .

Finally, we verify the static field directly with ognl :

ognl '@org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.User@ADMIN_ID'
@Integer[0]

Because commands like monitor , trace , and watch modify bytecode, it is necessary to run shutdown after the diagnosis to restore the original classes before exiting Arthas.

In summary, the case study demonstrates a complete workflow for diagnosing a high‑CPU problem with Arthas:

Use dashboard + thread to quickly locate the most CPU‑intensive threads and stack traces.

Decompile the relevant classes with jad to pinpoint the root cause.

If method arguments are unclear, employ watch to observe parameters and filter by execution time.

Besides Arthas, the article also mentions the Qunar open‑source tool Bistoury , which provides a visual interface, multi‑machine management, and online breakpoint debugging.

Finally, the author includes a promotional note encouraging readers to like, share, and subscribe, and advertises a paid “knowledge planet” with various Java and architecture courses.