Java线程死循环怎么定位 Java排查高CPU占用线程【实战】_技术教程

应先用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 -o THREAD,tid,time 输出的 TID 列也是LWP，但部分旧版ps不支持THREAD，优先用top -Hp更稳。

jstack 输出线程栈并匹配16进制线程ID

把上一步拿到的十进制线程PID转成十六进制（比如 27982 → 6d4e），然后用 jstack > jstack.out 抓全量线程快照。在文件里搜索 0x6d4e（注意前缀 0x），定位到对应线程的堆栈。

关键点：

必须用小写十六进制，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 metho d，加 --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()，结果反复空轮询