前言

线上告警这方面。CPU 飙到 100%，服务响应超时。打开终端、连服务器、执行 top、jstack…，这一套流程对老手来说行云流水，却让不少新人每次遇到性能问题都陷入“先看什么？用什么命令，怎么看线程栈？”的焦虑，

这篇文章了一套标准化的 Java 性能排障流程无论是 CPU 飙升、内存泄漏还是响应延迟。只需按步骤走，就能快速定位根因。

一、CPU 飙升排查

第 1 步：找到高 CPU 进程

# Linuxtop
# 找到进程 PID，例如 Java 进程 pid=12345
top

示例输出这方面。

PID USER PR NI VIRT RES SHR S %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
12345 root 20 0 10G 4G -S S 100.0 0.5 java

如果机器上只有一个 Java 进程，那它基本就是占用 CPU 的主因。

top -H -p 

该命令会列出该进程下所有线程及其 CPU 占用情况。找出 CPU 占用最高的线程，记下它的 TID。例如：

tid=1234567

第 3 步：将 TID 转为十六进制

printf "%x
" 
# 输出: a1234b

十六进制值将在后续 jstack 中定位线程。

第 4 步：导出线程栈并定位热点方法

jstack  | grep -A10 "0x&a1234b"

"http-nio--exec-8" # daemon prio= os_prio= tid=0x00007f... java.lang.Thread.State: RUNNABLE at com.example.service.PremiumCalculator.calculate at com.example.service.PremiumCalculator.lambda$batchCalculate$ ...

关注 RUNNABLE 状态 + 热点方法行号——这往往是导致 CPU 飙升的元凶。

常见 CPU 飙升根因汇总

二、内存泄漏排查

第 1 步：确认是否存在内存泄漏迹象

jstat -gcutil 
S = Survivor区；E = Eden区，O = Old区；M = MaxHeapSize
YGC/YGCT = Minor GC 次数/耗时
FGC/FGCT = Full GC 次数/耗时
`O` 继续增长 && `FGC` 越来越多 → 很可能是内存泄漏。话说回来，`
`
`

第 4 步：导出堆转储
bash
jmap -dump:live,format=b,file=/tmp/heap.hprof 
-XX这方面。
+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/

第 5 步：分析 Dump 文件
使用 **MAT** 或 **VisualVM** 打开 `/heap.hprof`：

`

`Leak Suspects` — 工具自动推测潜在泄漏点；

`Dominator Tree` — 按保留堆大小排序，快速定位最大对象；

`GC Roots` — 确认对象被谁引用，为什么不被回收。
`

`Object Query Language ` — 在 MAT 中直接写 SQL 类查询，以精确筛选感兴趣类实例。不过，`
`.

常见泄漏模式