JVM 常见问题之 CPU 100% 定位与解决

以下是 JVM 常见问题之 CPU 100% 定位与解决 的完整、系统化实战指南，涵盖从现象识别到根因分析、工具使用和解决方案，适用于 Java 应用（如 ZooKeeper、Kafka、Spring Boot 等）的线上故障排查。

🚨 JVM CPU 100% 问题定位与解决

当 Java 进程 CPU 使用率持续接近或达到 100%，会导致服务响应变慢、超时甚至不可用。这类问题通常由 死循环、频繁 GC、锁竞争、正则表达式性能差、序列化开销大 等引起。

一、问题现象

• top 显示某个 Java 进程 CPU 占用极高（如 200%~800%，多核环境下可能更高）
• 应用响应延迟增加，接口超时
• 日志无明显异常（有时是“静默”的性能问题）

top
# 输出示例：
PID   USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12345 admin     20   0 4614564 1.2g  12344 R  780.0 15.2   1:23.45 java

说明：该 Java 进程占用了约 7.8 个 CPU 核心（780%）

二、定位高 CPU 线程（Step-by-Step）

Step 1：使用 top -Hp <pid> 查看线程级 CPU 使用

top -Hp 12345

输出示例：

  PID USER      PR NI  VIRT  RES  SHR S %CPU MEM   TIME+ COMMAND
12348 admin     20  0 4614m 1.2g  12m R 77.8 15.2   0:15.21 java
12349 admin     20  0 4614m 1.2g  12m R 76.5 15.2   0:14.88 java
...

找到 CPU 占比最高的线程 ID（TID），例如 12348。

Step 2：将线程 ID 转为十六进制（用于匹配 jstack 输出）

printf "%x\n" 12348
# 输出：303c

Step 3：使用 jstack <pid> 获取线程栈信息

jstack 12345 > jstack.log

在 jstack.log 中搜索 nid=0x303c（注意加 0x 前缀）：

"main" #1 prio=5 os_prio=0 tid=0x00007f8a8c00a000 nid=0x303c runnable [0x00007f8a932fe000]
   java.lang.Thread.State: RUNNABLE
        at com.example.MyService.loopForever(MyService.java:45)
        at com.example.MyService.main(MyService.java:10)

✅ 找到了罪魁祸首：loopForever 方法中存在死循环！

三、常见原因分析与排查

四、结合 jstat 判断是否为 GC 导致

# 每秒输出一次 GC 情况
jstat -gcutil 12345 1000

输出示例：

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
100.00   0.00  98.72  78.21  95.12  90.23   123    1.234    15    10.567   11.801

• FGCT（Full GC Time）> 10s：说明 GC 停顿严重
• FGC 频繁增长：可能内存泄漏或堆设置不合理

🔍 如果 CPU 高 + FGCT 持续上升 → 问题根源是 GC

五、高级工具推荐

1. Arthas（Alibaba 开源诊断工具）

# 启动 Arthas
java -jar arthas-boot.jar

# 查看最忙的 3 个线程
thread -n 3

# 输出示例：
"main" CPU: 77.8% DAEMON
    at com.example.MyService.loopForever(MyService.java:45)
    at com.example.MyService.main(MyService.java:10)

✅ 优势：无需手动转换线程 ID，直接显示最忙线程及其栈

2. Async-Profiler + 火焰图（Flame Graph）

适用于复杂性能问题，能可视化 CPU 耗时分布。

使用步骤：

# 下载 async-profiler
git clone https://github.com/async-profiler/async-profiler.git

# 采样 30 秒 CPU 使用
./profiler.sh -e cpu -d 30 -f /tmp/flamegraph.html 12345

生成火焰图 flamegraph.html，打开后可直观看到：

• 哪个方法消耗最多 CPU
• 调用链深度
• 是否存在热点方法

📊 效果：一眼看出 String.intern()、regex、JSON.parse() 等热点

六、典型场景与解决方案

场景 1：死循环

while (true) {
    // 忘记 break 或 sleep
    process();
}

✅ 修复：添加 Thread.sleep(1) 或退出条件。

场景 2：正则表达式回溯灾难（Catastrophic Backtracking）

Pattern pattern = Pattern.compile("(a+)+$");
pattern.matcher("aaaaaaaaaaaaaaaaaaaaaab").matches(); // 极慢

✅ 修复：

• 使用非捕获组 (?:a+)
• 避免嵌套量词
• 使用 Pattern.compile(..., Pattern.CANON_EQ) 或限制输入长度

场景 3：频繁 Full GC

jstat -gcutil <pid> 1000
# FGC 每分钟增长一次，FGCT 持续上升

✅ 排查步骤：

1. jmap -histo <pid>：查看对象数量
2. jmap -dump:format=b,file=heap.hprof <pid>：生成堆转储
3. 使用 Eclipse MAT 或 JVisualVM 分析内存泄漏

✅ 解决方案：

• 调整堆大小：-Xms4g -Xmx4g
• 使用 G1GC：-XX:+UseG1GC
• 修复内存泄漏代码（如静态集合未清理）

场景 4：锁竞争

"Thread-1" #12 prio=5 os_prio=0 tid=0x00007f8a8c00a000 nid=0x303c blocked
  - waiting to lock <0x000000076b8a1234> (a java.lang.Object)
  at com.example.Counter.increment(Counter.java:20)

✅ 优化：

• 使用 ConcurrentHashMap 替代 synchronized Map
• 减小锁粒度
• 使用 ReentrantLock 或无锁结构（如 CAS）

七、预防措施与最佳实践

八、完整排查流程图

[CPU 100%] → top -Hp <pid> → 找高 CPU 线程 TID
       ↓
   printf "%x" TID → 转十六进制
       ↓
   jstack <pid> → 搜索 nid=0x... → 定位线程栈
       ↓
   是 RUNNABLE？ → 查代码：死循环/正则/序列化
       ↓
   是 BLOCKED？ → 锁竞争
       ↓
   结合 jstat -gcutil → 是否 GC 导致
       ↓
   必要时：Arthas / Async-Profiler 火焰图深入分析

✅ 总结：JVM CPU 100% 处理口诀

🔎 一查 top：top -Hp 找线程
🔁 二转 hex：printf "%x" 转十六进制
🧩 三看 jstack：jstack 找 nid 对应栈
♻️ 四验 GC：jstat -gcutil 看是否频繁 GC
🛠️ 五用工具：Arthas 快速定位，火焰图可视化
📦 六修代码：修复死循环、正则、锁等问题

📌 最终建议：

CPU 100% 是线上最常见的性能问题之一。掌握这套方法论，结合 Arthas 和 Async-Profiler，可快速定位绝大多数问题。

对于关键服务，建议预装诊断工具，并建立 标准化故障响应流程（SOP），提升 MTTR（平均恢复时间）。