应先用top -Hp 按Shift+P找出高CPU线程PID（LWP），再转十六进制后用jstack匹配0x前缀定位堆栈；偶发问题可用Arthas trace动态追踪方法调用频次，最后检查volatile缺失、条件未更新等死循环陷阱。
top -Hp 查出高CPU的线程PID
Java进程整体CPU飙高，第一反应不是看代码，而是确认「哪个线程在吃CPU」。Linux下直接用 top -Hp ，按 Shift+P 降序排列，一眼就能看到占用率最高的线程ID（十进制）。注意：这个PID是操作系统级的线程ID（LWP），不是Java里的Thread.getId()（后者是JVM自增long值，完全无关）。
常见误区：ps -mp 输出的 TID 列也是LWP，但部分旧版ps不支持THREAD，优先用top -Hp更稳。
jstack 输出线程栈并匹配16进制线程ID
把上一步拿到的十进制线程PID转成十六进制（比如 27982 → 6d4e），然后用 jstack 抓全量线程快照。在文件里搜索 0x6d4e（注意前缀 0x），定位到对应线程的堆栈。
关键点：
立即学习“Java免费学习笔记（深入）”；
- 必须用小写十六进制，
jstack输出的tid=0x6d4e是小写，大写搜不到 - 如果搜不到，检查是否用了
-XX:+UseContainerSupport（Docker环境常见），此时jstack可能受限；可尝试加-F强制 dump：jstack -F - 死循环线程通常卡在某个方法里，堆栈最后一行往往是重复调用点，比如
at com.example.XxxService.loopCheck(XxxService.java:45)，且java.lang.Thread.State: RUNNABLE
结合Arthas trace命令动态追踪热点方法
如果问题偶发、jstack抓不到瞬间状态，或者想确认是不是某方法内部有隐式死循环（比如 while(true) + 条件判断被编译器优化），用 arthas 更准。启动后执行：
trace *XxxService loopCheck
它会实时统计该方法的调用耗时和次数。若发现单次调用时间极短但每秒调用上千次，基本就是循环体没退出条件。
注意事项：
-
trace有性能开销，别在生产核心链路长期开着 - 若方法被JIT编译过，可能显示
not found method，加--skip-jdk-methods false或先用jad确认类是否已加载 - 对
while(true)本身无法 trace，但它的调用者或内部频繁调用的子方法（如System.currentTimeMillis()、queue.poll()）会暴露异常调用频次
检查常见死循环陷阱：volatile缺失、条件变量未更新
定位到具体方法后，重点看循环控制逻辑。高频坑点：
- 共享变量没用
volatile修饰，导致线程始终读缓存值，条件永远为真 —— 比如while (!shutdown)中shutdown是普通 boolean 字段 - 循环内没有实际推进状态的语句，比如
while (list.size() > 0) { list.remove(0); }写成list.remove(i)但忘了i++ - 浮点数比较用
==，因精度丢失导致条件永不满足 - 阻塞队列判空后直接
poll()而非take()，结果反复空轮询
这类问题往往在测试环境不复现，因为线程调度节奏不同，一上线就卡死。加日志只是辅助，真正要改的是同步语义和变量可见性。
