值班群里最常见的告警是「CPU 100%」。很多人的第一反应是敲一次 `jstack`，把输出里 `RUNNABLE` 的线程挑出来，对着那一行的代码开始改。本文用本机 JDK 17 跑三组最小复现，回答一个很具体的问题：**一张线程快照到底能不能定位热点**。结论先放这里：不能。`RUNNABLE` 只是 JVM 里的线程状态，不是 CPU 占用的证明；真正稳的信号是「累计 CPU 时间 + 连续多次采样里重复的栈顶帧」。

## 假设

1. 一次 `jstack` 里所有 `RUNNABLE` 线程都在消耗 CPU 吗？
2. 只采一次栈，能不能抓到「一阵一阵」的热点？
3. 把 CPU 时间和栈顶稳定性合起来，能不能把候选收敛到唯一一条线程？

## 实验环境

- OpenJDK 17.0.20.1（Temurin / Windows），`java`、`javac`、`jstack` 均取自 `D:/Program Files/Java/jdk-17.0.20.1/bin`。
- 单个 `.java` 文件，`javac -encoding UTF-8` 编译后 `java -cp . <类名>` 运行；用 `ProcessHandle.current().pid()` 取自身 pid，再由 `ProcessBuilder` 调同 JDK 的 `jstack.exe <pid>` 抓栈。
- 度量方式：`ThreadMXBean.getThreadCpuTime`（先 `setThreadCpuTimeEnabled(true)`）取累计 CPU 时间；栈解析**只取线程块第一行 `at ` 帧作为栈顶**，不判断整个块里是否出现某方法名。这个区别在实验二里会变得很关键。
- 采样：实验一连采 3 次、间隔 300 ms；实验二连采 6 次、间隔 330 ms。
- 以下是**演示性测量**：线程由本机最小程序构造，未起真实线上服务、未连 Kubernetes、未做多实例对照，也未安装 Arthas。真实场景请用 JMH 或生产 APM 复核，不要把这里的毫秒数当容量数据。

## 实验一：只看 RUNNABLE 能定位热点吗

这段代码要证明什么：造出三个「状态各不相同」的线程，看状态和 CPU 时间是否一一对应。

```java
// JDK 17+；完整程序在本机归档，这里只贴起线程的关键部分
static volatile boolean running = true;
static volatile long sink;              // volatile 写阻止 JIT 把循环消掉

static void spin() {
    long x = 0;
    while (running) { sink = ++x; }
}

static void idle() {
    while (running) {
        try { Thread.sleep(20); } catch (InterruptedException e) { return; }
    }
}

ServerSocket server = new ServerSocket(0);
Thread hog  = new Thread(CpuHotspotLab::spin, "cpu-hog");
Thread idle = new Thread(CpuHotspotLab::idle, "idle-timer");
Thread net  = new Thread(() -> {
    try { server.accept(); } catch (IOException ignored) { }
}, "net-accept");
```

`cpu-hog` 是纯整数运算的死循环，`idle-timer` 在睡觉，`net-accept` 阻塞在没有连接的 `ServerSocket.accept()` 上。三次采样间隔 300 ms，窗口 1583 ms，结果如下：

| 线程 | jstack 状态（3/3 一致） | 栈顶帧 | 窗口内 CPU 时间 |
| --- | --- | --- | --- |
| `cpu-hog` | RUNNABLE | `CpuHotspotLab.spin` | 1593 ms |
| `net-accept` | RUNNABLE | `sun.nio.ch.Net.accept` (Native Method) | 0 ms |
| `idle-timer` | TIMED_WAITING | `java.lang.Thread.sleep` (Native Method) | 0 ms |

**结论：两个 RUNNABLE 里只有一个真在吃 CPU。** 所以对你写代码意味着什么——按状态筛只能把候选从 3 个缩到 2 个，不能定性；把 native 阻塞误判成业务死循环，会让你去改一段根本没问题的网络代码。

顺带解释 1593 > 1583：两者起点不同（CPU 时间基线在线程稳定之后取，窗口从第一次 `jstack` 开始），且 `jstack` attach 本身有开销。量级上约等于窗口长度，说明单线程吃满一个逻辑核，不要把它读成「CPU 超过 100%」的异常。

补一句关于可复现性：循环里对 `volatile` 字段的写入是有意为之。若只做 `x++` 而没有任何副作用，JIT 完全可能把整个死循环优化掉，实验会跑出「一个不吃 CPU 的死循环」，数据全废。这也是 JVM 上的微基准必须交给 JMH 的原因；本文数字只用于说明机制差异，不作性能结论。上面两段 Java 片段为了让读者能独立拼接运行，保留了必要的字段与线程声明，按代码规范放宽到 25 行以内。

## 实验二：一次栈快照够不够

这段代码要证明什么：把热点改成「忙一阵、歇一阵」，看单次采样会不会扑空。

```java
// JDK 17+；忙 120 ms + 不定长 sleep，模拟偶发热点
static void burst() {
    int round = 0;
    while (running) {
        long end = System.nanoTime() + 120_000_000L;
        long x = 0;
        while (running && System.nanoTime() < end) { sink = ++x; }
        try { Thread.sleep(80 + (round++ * 37) % 320); }
        catch (InterruptedException e) { return; }
    }
}
```

6 次采样（间隔 330 ms，窗口 3248 ms）的栈顶判定：

| 采样 | 1 | 2 | 3 | 4 | 5 | 6 |
| --- | --- | --- | --- | --- | --- | --- |
| 栈顶是 `burst()` | 否 | 是 | 否 | 是 | 是 | 否 |

`busy-top-hits=3/6`，而 `ThreadMXBean` 在同一窗口累计 `1140 ms` CPU 时间，约占单核 `0.35`。

**结论：单次快照有约一半概率扑空。** 所以对你写代码意味着什么——线上要连采 3 次以上再看栈顶是否重复；但 CPU 时间是累计量，即便采样全落在「歇」的那一段，它仍能把这条线程排到前面。

这里还有一个容易自己骗自己的地方：我第一版判据写成「线程块里有没有 `BurstyHotspotLab.burst`」，结果 6/6 全命中。原因是线程在 `sleep` 时，`burst()` 这个栈帧仍然挂在下面——只有取**第一行 `at` 帧**（栈顶）才能区分忙和歇。这个判据错误当时差一点被写成「单次采样 100% 命中」的错误结论。排查工具本身也需要被排查。

## 实验三：按线上顺序把两个信号合起来

这一节不产生新数字，只是把实验一的读数按真实处置顺序复算一遍，验证判别规则能不能收敛到唯一答案。

```bash
# 拿到 pid 后连采 3 次；Linux 上可换成 jcmd <pid> Thread.print
jstack <pid> > dump-1.txt
sleep 1
jstack <pid> > dump-2.txt
sleep 1
jstack <pid> > dump-3.txt
```

| 步骤 | 用的信号 | 剩余候选 | 被淘汰的 |
| --- | --- | --- | --- |
| 0 | 全部线程 | 3 | — |
| 1 | 状态 = RUNNABLE | 2 | `idle-timer` |
| 2 | 三次栈顶稳定重复 | 2 | 无（`net-accept` 也稳定在 `Net.accept`） |
| 3 | 累计 CPU 时间 > 0 | 1 | `net-accept` |

**结论：第 2 步筛不掉 native 阻塞，第 3 步才是定性的那一步。** 所以对你写代码意味着什么——把「栈顶稳定」用来确认「就是这段代码」，把「CPU 时间」用来确认「就是这条线程」；两个信号分工不同，别互相替代。

## 数据背后的原理

`jstack` 打印的是某一瞬间每个线程「最后停在哪一行」。它和 CPU 使用率的关系，像医院急诊：CPU 使用率是候诊大厅里有多少人，线程栈是给每个人拍一张 X 光，线程 CPU 时间是心电监护的累计读数。**类比的局限**有三条：现实分诊按病情紧急程度，线程按操作系统时间片调度；X 光是瞬时切片，看不到拍摄之前发生了什么；而阻塞在 native 方法里的线程，在照片上同样是「站着的人」，其实一直在等一个不会来的连接。

专业定义：`Thread.State.RUNNABLE` 在 JVM 里表示线程「可执行」，包含正在 CPU 上跑、就绪等待调度，以及**正在执行 native 方法且该 native 方法阻塞在 OS 层**这三类。HotSpot 不区分「Java 层在跑」和「native 层在等」，所以 `Net.accept` 仍显示 RUNNABLE。

按关系把关联知识串起来，这是本文的知识地图：

- **线程状态枚举**：它是筛选入口——不先按状态切一刀，你会在几十个线程里逐行读栈；但它只负责缩小范围，不负责定性。
- **native 方法与 `RUNNABLE`**：它是误判来源——`Net.accept`、`FileInputStream.readBytes` 这类 native 阻塞不改 JVM 线程状态。
- **`ThreadMXBean.getThreadCpuTime`**：它是定量信号——统计该线程真正在 CPU 上执行的累计纳秒数，与「是不是 RUNNABLE」正交。
- **`jstack` / `jcmd Thread.print`**：它们是取栈工具——输出格式接近，`jcmd` 还能顺带取 `VM.flags`；本文只用 `jstack`，未在容器里验证 `jcmd`。
- **栈顶帧（top frame）**：它是代码定位依据——只有栈顶那一行能对到具体方法；更低层的帧会一直挂着，正是实验二判据翻车的原因。
- **采样间隔**：它决定偶发热点的检出率——间隔越接近热点周期，越容易锁相漏采；本文用 330 ms 配 120 ms 忙循环，命中 3/6。
- **GC 线程与 JIT 编译线程**：它们是另一类嫌疑——容器里 CPU 高时，`GC Thread` 或 `C2 CompilerThread` 排前几位往往是 GC 抖动或启动期编译，不是业务死循环。本文未做 GC 压测，仅作机制说明。
- **`top -H` / `pidstat -t`**：它们是 Linux 侧的对应关系——`jstack` 里的 `nid`（十六进制）要换算成十进制才能对上 `top -H` 的 tid；本文在 Windows 实测，这一步未验证。
- **Arthas `thread -n 3` / `dashboard`**：它是封装形态——把「按 CPU 时间排序 + 打栈」合成一条命令，机制与本文一致，本文未安装 Arthas 实测。
- **死循环、正则回溯、大对象序列化**：它们是常见业务成因——定位到栈顶之后改哪一行靠这一类经验，和「怎么找到那一行」是两个问题。

```mermaid
flowchart TD
    A[CPU 100% 告警] --> B[取 pid]
    B --> C[连续 3 次 jstack]
    B --> D[ThreadMXBean CPU 时间]
    C --> E[筛 RUNNABLE]
    E --> F[看栈顶是否重复]
    D --> G[按 CPU 时间排序]
    F --> H{栈顶稳定且 CPU 时间大于 0}
    G --> H
    H -->|是| I[定位到具体方法行]
    H -->|否| J[换嫌疑: GC / JIT / native 阻塞]
```

## 反直觉的发现

1. **RUNNABLE 里有一半是「假热点」**：`net-accept` 三次全 RUNNABLE，CPU 时间 0 ms。
2. **多次采样也可能「稳定地错」**：`net-accept` 的栈顶三次都是 `Net.accept`，稳定性筛不掉它；稳定只说明「一直卡在这儿」，不说明「在烧 CPU」。
3. **判据写松一格，结论就反过来**：实验二第一版用 `contains` 得到 6/6，改成「只取栈顶 `at` 帧」变成 3/6。
4. **CPU 时间能超过墙钟窗口**：1593 ms > 1583 ms 不是数据错，是基线起点、attach 开销与调度共同造成的；看量级，别看末位。

## 前置知识

- **线程栈（stack trace）**：一次快照里从栈顶到栈底的方法调用链，栈顶是「此刻正在执行的方法」。
- **线程状态**：`RUNNABLE` / `BLOCKED` / `WAITING` / `TIMED_WAITING` 是 JDK 层抽象，与操作系统的运行 / 阻塞不是一一对应。
- **CPU 时间**：线程真正在 CPU 上跑的累计时长，区别于墙钟时间；`ThreadMXBean` 需要显式 `setThreadCpuTimeEnabled(true)` 才能读到。
- **native 方法**：由 JVM 用 C/C++ 实现的方法，jstack 里常标 `Native Method`，其内部阻塞不会改变 JVM 线程状态。

## 常见坑与面试高频

- 问：`jstack` 里 RUNNABLE 线程很多，CPU 就一定高吗？答：不一定，native 阻塞也是 RUNNABLE，要看累计 CPU 时间。
- 问：为什么要连采几次？答：单次是瞬时切片，偶发热点会漏；连采看栈顶是否重复。
- 问：`nid` 怎么和 `top` 对上？答：jstack 的 `nid` 是十六进制，转十进制对应 Linux 的 tid（本文 Windows 未验证）。
- 问：容器里 CPU 100% 但业务线程都很闲？答：先看 GC 线程与 cgroup 限额，别急着改业务代码。

## 落到线上：20 分钟里的顺序

把上面的结论按值班时的动作排一遍，顺序是有讲究的：

1. **先确认口径**。监控给的是「进程 CPU 100%」还是「整机 100%」？单线程死循环通常只吃满一个逻辑核，多核机器上整机未必满。容器里还要先看 cgroup 的 `cpu.stat`，别把限流当成业务热点。
2. **取 pid 并连采 3 次栈**，间隔 1 秒左右。不要更密：每次 attach 都要暂停线程取快照，本实验里三次采样加解析就占了 1583 ms，高频轮询本身会改变你要观察的对象。
3. **同时取一次线程 CPU 时间排序**。没有 APM 时，`jcmd <pid> Thread.print` 与 `ThreadMXBean` 是两条成本最低的入口；装了 Arthas 的话，`thread -n 3` 就是把这一步封装好了。
4. **把两份结果对照**：CPU 时间排前几名、且三次栈顶指向同一个业务方法的那条线程，才是要改的对象。栈顶若是 `GC Thread`、`C2 CompilerThread` 或某个 native 方法，先别动业务代码。
5. **改完再采一次**，验证 CPU 时间和栈顶都掉下来。只验证「CPU 降了」不够，可能只是流量回落；栈顶变化才能确认改到了那一处。

这套顺序的价值在于把「猜」换成「排除」：实验三里候选数 3 → 2 → 2 → 1 的每一步，都对应一个能写进值班手册的判断条件。它同时也是本文的适用边界——一旦涉及多实例，热点可能在另一台机器上，这套单 JVM 内的排序就只覆盖了其中一部分。

## 结论速查表 + 选型建议

| 你手上有什么 | 能回答什么 | 不能回答什么 |
| --- | --- | --- |
| 一次 `jstack` | 这一刻每个线程停在哪一行 | 谁在吃 CPU、偶发热点有没有被漏掉 |
| 连续 3 次 `jstack` | 栈顶是否稳定、是不是一直卡在同一处 | 稳定运行 ≠ 高 CPU |
| `getThreadCpuTime` 排序 | 谁真的占用了 CPU、占用多久 | 具体是哪一行代码 |
| 两者合起来 | **哪条线程的哪一行** | 容器 / 多实例下的归因 |

三个典型场景：单 JVM 的后台任务突然打满一个核，先按 CPU 时间排序再连采 3 次栈；网关 / RPC 服务的线程数很多而 CPU 不高，重点看是不是 native 阻塞被误读；容器里 Pod 被限流但进程内看着正常，要先分清是 cgroup 限额还是业务线程。选型上，单 JVM 内用「CPU 时间排序 → 3 次栈确认栈顶」这套；需要长期趋势就交给 APM，不要用 `jstack` 高频轮询，每次 attach 都有开销。

## 收尾：结论的适用边界

三句话带走：**第一**，`RUNNABLE` 只筛候选，不定性；**第二**，单次栈快照会漏掉偶发热点，连采 3 次看栈顶是否重复；**第三**，把累计 CPU 时间和栈顶合起来，才能收敛到唯一那一行。

这些结论在本机 JDK 17.0.20.1、单 JVM、单文件最小程序下成立。以下情况会失效：容器里 CPU 限额被压满时，进程内看到的 CPU 时间与宿主机口径不一致；多实例部署时，热点可能在另一个 Pod；native 方法内部若真在做 CPU 密集运算而非阻塞，`RUNNABLE` 与 CPU 时间会同时升高，本文的「0 ms」对照不再适用；不同 JDK 版本对线程状态与 `getThreadCpuTime` 的实现细节也可能有差异。本文未连真实服务、未做 GC 压测、未安装 Arthas，涉及它们的部分只作机制说明。

知识图谱回顾：告警 → pid →（三次栈 / CPU 时间）→ 候选收敛 → 栈顶定位 → 区分业务 / GC / JIT / native 阻塞。

延伸阅读（同系列主题，无链接）：线程状态与 `Object.wait` → `ThreadMXBean` 与 JMH 基准方法 → `jcmd` 与 JVM 诊断命令族 → GC 线程与 G1 日志 → JIT 编译线程与预热 → Linux `top -H` 与 nid 换算 → 容器 CPU 限额与 cgroup → 链路追踪里的慢请求归因。

以上是本机最小复现场景，非真实事故原始记录。完整实验脚本与输出已在本机归档，欢迎在评论区交流这三种信号在你们线上的实际形态，也欢迎指正。


值班群里最常见的告警是「CPU 100%」。很多人的第一反应是敲一次 jstack，把输出里 RUNNABLE 的线程挑出来，对着那一行的代码开始改。本文用本机 JDK 17 跑三组最小复现，回答一个很具体的问题：一张线程快照到底能不能定位热点。结论先放这里：不能。RUNNABLE 只是 JVM 里的线程状态，不是 CPU 占用的证明；真正稳的信号是「累计 CPU 时间 + 连续多次采样里重复的栈顶帧」。

【Java·排障】CPU 100% 的定位顺序：3 组实测对照 RUNNABLE、栈顶稳定性与线程 CPU 时间

CPU 100% 该抓哪个线程？用本机 JDK 17 跑三组最小复现：3 次 jstack 里 cpu-hog 与 net-accept 都是 RUNNABLE，但累计 CPU 时间是 1593 ms 对 0 ms；偶发热点 6 次采样只命中 3 次栈顶。按 CPU 时间排序、连采 3 次栈、再反查代码收敛到唯一一行，并写清 native 阻塞为何被误判、栈顶首帧判据与容器下的边界。

编程语言

CPU100%告警中RUNNABLE状态≠CPU占用证明，native阻塞如Net.accept也显示RUNNABLE。单次jstack会漏掉偶发热点，需连采3次看栈顶稳定性，结合ThreadMXBean累计CPU时间排序才能定位热点线程。本机JDK17实验验证栈顶帧判断比contains更准确，多实例或容器限流场景需调整方法。

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

CPU100%告警中RUNNABLE状态≠CPU占用证明，native阻塞如Net.accept也显示RUNNABLE。单次jstack会漏掉偶发热点，需连采3次看栈顶稳定性，结合ThreadMXBean累计CPU时间排序才能定位热点线程。本机JDK17实验验证栈顶帧判断比contains更准确，多实例或容器限流场景需...

【Java·排障】CPU 100% 的定位顺序：3 组实测对照 RUNNABLE、栈顶稳定性与线程 CPU 时间-腾讯云开发者社区-腾讯云

【Java·排障】CPU 100% 的定位顺序：3 组实测对照 RUNNABLE、栈顶稳定性与线程 CPU 时间

【Java·排障】CPU 100% 的定位顺序：3 组实测对照 RUNNABLE、栈顶稳定性与线程 CPU 时间

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐