Java 线上排查标准手册：CPU 飙高、内存泄漏、接口慢，jstack/jmap/jstat 命令速查

Java 线上排查标准手册：CPU 飙高、内存泄漏、接口慢，jstack/jmap/jstat 命令速查

目录

• 一、前置准备：看一眼 top 确定方向
• 二、CPU 飙高排查
• 三、内存泄漏 / OOM 排查
• 四、接口响应慢排查
• 五、死锁排查
• 六、线程数异常排查
• 七、JVM 参数推荐
• 八、命令速查总表

一、前置准备：看一眼 top 确定方向

所有排查的第一步——确认问题类型：

# 找到 Java 进程 PID jps -l # 或 pgrep -f java # 看 CPU 和内存 top -p <java_pid>

PID USER %CPU %MEM TIME+ COMMAND 12345 root 95.2 8.3 12:30.15 java

决策树：

top 看到什么 → 走哪条路径 ───────────────────────────────── %CPU > 80% 且持续 → 第二章「CPU 飙高」 %MEM 持续上涨 → 第三章「内存泄漏」 %CPU/%MEM 正常但慢 → 第四章「接口慢」 线程数异常增加 → 第六章「线程异常」

二、CPU 飙高排查

2.1 找到吃 CPU 的线程

# -H：显示线程级别 # -p：指定进程 top -Hp <java_pid>

输出示例：

PID USER %CPU %MEM TIME+ COMMAND 12399 root 92.1 0.1 5:30.15 java ← 这个线程吃了 92% CPU 12345 root 1.2 8.3 12:30.15 java 12401 root 0.5 0.1 0:10.22 java

记下最忙线程的 PID（这里是 12399）。

2.2 PID 转十六进制

printf "%x\n" 12399 # 输出：306f

2.3 jstack 定位代码行

# 打印线程栈，grep 过滤目标线程 jstack <java_pid> | grep -A 30 "0x306f"

输出解读：

"http-nio-8080-exec-5" #42 daemon prio=5 os_prio=0 tid=0x... nid=0x306f runnable java.lang.Thread.State: RUNNABLE at com.example.OrderService.queryOrders(OrderService.java:87) at com.example.OrderController.list(OrderController.java:23) at javax.servlet.http.HttpServlet.service(HttpServlet.java:...) ...

2.4 持续采样确认

# 每 3 秒采样一次，共 5 次，看是否卡在同一行 for i in $(seq 1 5); do echo "=== Sample $i ===" jstack <java_pid> | grep -A 5 "0x306f" sleep 3 done

5 次都在同一行→ 死循环或密集计算，改代码。
每次在不同行→ 高并发请求打进来，考虑扩容或限流。

三、内存泄漏 / OOM 排查

3.1 jstat 看 GC 概况

# 每 1 秒输出一次，共 10 次 jstat -gc <java_pid> 1000 10

输出列说明：

S0C S1C S0U S1U EC EU OC OU MC MU Survivor区 Survivor区 Eden区 Eden区 老年代容量 老年代使用量 元空间 容量 使用量 容量 使用量

重点关注：

jstat -gc <java_pid> 1000 5 | awk ' NR==1 {print "老年代使用率 | YGC | YGCT | FGC | FGCT | GCT"} NR>1 { ou=$8; oc=$7; rate=(oc>0 ? ou/oc*100 : 0); printf " %.1f%% | %4d | %5.2f | %3d | %5.2f | %5.2f\n", rate,$9,$10,$11,$12,$13 }'

3.2 jmap -histo 快速定位嫌疑类

# 按实例数降序排列，看前 30 个类 jmap -histo <java_pid> | head -30

输出：

num #instances #bytes class name 1: 1827364 438567360 [C ← char[]（通常是 String） 2: 1523456 365629440 java.lang.String 3: 234567 56194080 java.util.HashMap$Node 4: 123456 29629440 com.example.dto.OrderDTO ← ⚠️ 你的 DTO 5: 98765 23703600 java.util.ArrayList

分析思路：

• char[]和String排前两名正常—— 任何 Java 应用都这样
• 你的业务类（DTO、Entity）突然排进前 10—— 大概率是内存泄漏点
• HashMap$Node异常多—— 某个 Map 在不断增长却没清理

3.3 jmap -dump 生成 heap dump

# 生成 heap dump 文件 jmap -dump:format=b,file=/tmp/heap_$(date +%Y%m%d_%H%M%S).hprof <java_pid>

⚠️ dump 期间 JVM 会暂停（STW），线上慎用。优先用-histo快速诊断。

3.4 让 JVM 在 OOM 时自动 dump

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/heap.hprof -XX:OnOutOfMemoryError="kill -9 %p" # OOM 后自动重启（可选）

3.5 内存泄漏常见根因

四、接口响应慢排查

4.1 看线程状态分布

# 统计各状态的线程数量 jstack <java_pid> | grep "java.lang.Thread.State" | sort | uniq -c | sort -rn

输出示例：

127 java.lang.Thread.State: WAITING (parking) 45 java.lang.Thread.State: TIMED_WAITING (parking) 12 java.lang.Thread.State: BLOCKED 8 java.lang.Thread.State: RUNNABLE

4.2 找到阻塞源头

# 看 BLOCKED 状态的线程在等哪个锁 jstack <java_pid> | grep -A 30 "BLOCKED"

关键信息：

- waiting to lock <0x00000007a1b2c3d8> (a java.util.HashMap) - locked <0x00000007a1b2c3d8> (a java.util.HashMap) at ...

持有锁的线程在干什么？如果在做 I/O，那就是锁粒度过大。

4.3 检查数据库连接池

# 看有多少线程在等 HikariCP 连接 jstack <java_pid> | grep -c "HikariPool.*getConnection"

如果这个数字接近maximum-pool-size，连接池满了。

五、死锁排查

5.1 jstack 自动检测死锁

jstack <java_pid> | grep -A 50 "deadlock"

jstack 会自动检测死锁并在输出末尾列出。如果存在死锁，输出会明确标注：

Found one Java-level deadlock: ============================ "Thread-1": waiting to lock monitor 0x00007f... (object 0x00000007a1b2c3d8, a java.lang.Object), which is held by "Thread-2" "Thread-2": waiting to lock monitor 0x00007f... (object 0x00000007a1b2c3e0, a java.lang.Object), which is held by "Thread-1" Java stack information for the threads listed above: ===================================================

5.2 如果没有自动检测

# 手动搜 BLOCKED 线程及其等待的锁 jstack <java_pid> | grep -B 2 -A 10 "waiting to lock"

六、线程数异常排查

6.1 查看总线程数

# 方式一 jstack <java_pid> | grep "^""" | wc -l # 方式二：查看线程列表 jcmd <java_pid> Thread.print | grep "^""" | wc -l

6.2 按线程名分组统计

jstack <java_pid> | grep "^""" | awk -F'"' '{print $2}' | \ sed 's/-[0-9]*$//' | sort | uniq -c | sort -rn | head -20

输出：

200 http-nio-8080-exec 50 SimpleAsyncTaskExecutor 30 scheduling- 10 HikariPool

七、JVM 参数推荐

# 生产环境基线 JVM 参数 java \ -Xms4g -Xmx4g \ # 堆大小，min=max 避免动态扩缩 -XX:+UseG1GC \ # G1 收集器（大堆首选） -XX:MaxGCPauseMillis=200 \ # GC 停顿目标 200ms -XX:+HeapDumpOnOutOfMemoryError \ # OOM 自动 dump -XX:HeapDumpPath=/data/dump/ \ # dump 路径 -XX:+PrintGCDetails \ # GC 日志 -XX:+PrintGCDateStamps \ -Xloggc:/data/logs/gc.log \ -jar app.jar

八、命令速查总表

症状 第一步命令 第二步 第三步 ──────────────────────────────────────────────────────────────────────────── CPU 飙高 top -Hp <pid> printf "%x\n" <tid> jstack <pid> | grep 0x<hex> 定位到代码行 内存上涨 jstat -gc <pid> 1000 10 jmap -histo <pid> jmap -dump:format=b,file=... → 看 OU/OC 使用率 → 找嫌疑类 → 离线分析 Full GC 频繁 jstat -gc <pid> 1000 5 jmap -histo <pid> 同上 → 看 FGC 次数和耗时 → 确认泄漏 接口慢 jstack <pid> | grep jstack <pid> | grep 检查慢 SQL、连接池、 "Thread.State" -A 30 "BLOCKED" 下游 HTTP 超时 → 看状态分布 → 分析阻塞链 死锁 jstack <pid> | grep jstack 输出末尾自动 -A 50 "deadlock" 标注死锁详情 线程数异常 jstack <pid> | grep 按线程名分组统计 "^""" | wc -l → 定位线程泄漏源 OOM 已发生 查看 hs_err_pid.log jmap -dump（如仍在运行） MAT / JProfiler → JVM 崩溃日志 → 分析 dump → 找最大对象

核心原则：先确定症状类型，再走对应路径。不要上来就 jstack 全量 dump 然后人肉分析——"先分类，再深入"比"一把梭"快十倍。

📋文章摘要

本文系统整理了 Java 线上问题排查的标准命令和完整路径。覆盖六大场景：CPU 飙高（top -Hp → printf 转十六进制 → jstack 定位代码行）、内存泄漏（jstat 看 GC → jmap -histo 找嫌疑类 → jmap dump 离线分析）、接口慢（线程状态分布 → 阻塞链分析 → 连接池检查）、死锁、线程数异常、OOM 应急处理。每个场景配有完整命令示例、输出解读表和决策逻辑，文末附 JVM 生产参数推荐和命令速查总表。适合需要不依赖 Arthas 等第三方工具、用 JDK 自带命令完成排查的 Java 后端开发者。