top和vmstat是Java生产环境CPU飙高时首选命令：top定位高CPU进程及线程，vmstat分析CPU消耗类型（us/sy/wa）并联动验证根因。
直接上手，不用绕弯——Java 生产环境 CPU 飙高，top 和 vmstat 是你最先该敲的两个命令，它们分工明确：top 看“谁在吃”，vmstat 看“为什么吃”。
用 top 快速锁定高 CPU 的 Java 进程和线程
执行 top，按 Shift + P 按 CPU 使用率倒序，一眼就能揪出占用最高的 Java 进程（注意看 %CPU 列）。记下它的 PID（比如 12345）。
接着执行：top -H -p 12345
这会进入线程视图。再按 Shift + P，就能看到该进程中哪些线程（TID）在疯狂占 CPU。挑出最靠前的一两个 TID（比如 12347），准备下一步分析。
小提示：
• 如果 %CPU 总和远超 100%，说明是多核并行消耗，正常；
• 如果单个线程 %CPU 接近 100%，大概率是死循环或密集计算；
• 注意看 STATE 列：R（运行中）是重点，D（不可中断睡眠）则可能卡在 I/O，别误判为 CPU 问题。
用 vmstat 判断 CPU 飙高的类型根源
运行：vmstat 1 5
它每秒采样一次，共 5 次，输出关键列含义如下：
- r：就绪队列长度。如果长期 > CPU 核数（比如 8 核服务器 r 常为 10+），说明 CPU 真的不够用，任务在排队
- us（用户态）高（>60%）→ 业务代码或 JVM 自身计算密集（如频繁 GC、正则匹配、JSON 解析）
- sy（内核态）高（明显高于 us）→ 可能是锁竞争、频繁系统调用（如大量 socket read/write）、或线程上下文切换太猛
- wa（I/O 等待）高（>20%）→ CPU 其实在干等磁盘或网络，不是真忙，要查 I/O 而非代码
- id（空闲）持续为 0 → CPU 已满载，需立即干预
例如输出中 us 85 sy 10 wa 2 id 3，基本可断定是 Java 应用自身逻辑或 GC 导致；若 us 20 sy 5 wa 70，那问题根本不在 CPU，而在磁盘响应慢或日志刷盘太猛。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
top 和 vmstat 联动验证的关键信号
单看 top 可能被“瞬时尖峰”误导，单看 vmstat 又不知具体是哪个进程。两者结合才能闭环：
立即学习“Java免费学习笔记（深入）”；
- top 找到高 CPU 进程 → vmstat 看
us/sy/wa比例 → 若us主导，立刻进该进程查线程 - vmstat 发现
r长期 > 核数，但 top 里没单个进程特别突出 → 很可能是大量小线程集体消耗（如连接池打满、定时任务堆积） - top 显示某 Java 进程 %CPU 高，vmstat 却显示
wa也高 → 该进程可能在做同步 I/O（如未异步化的日志写入、数据库查询），线程阻塞后又快速唤醒，造成 CPU 抖动
这时不要急着杀进程，先用 jstack 12345 > stack.log 抓堆栈，再结合线程 TID 的 16 进制（printf "%x\n" 12347）去日志里搜，看它到底卡在哪行代码或哪个框架方法里。
