线程死循环最典型的外在表现是该线程长期处于RUNNABLE状态且CPU占用持续偏高，不阻塞、不等待、不休眠，反复执行同一段逻辑；可通过jstack筛选RUNNABLE线程并检查堆栈是否反复落在同一行代码，结合top -H与十六进制TID精准定位，同时需区分密集计算等正常RUNNABLE场景。
线程死循环最典型的外在表现是：该线程长期处于 RUNNABLE 状态，且 CPU 占用持续偏高。它不阻塞、不等待、不休眠，只是反复执行同一段逻辑，导致 CPU 时间片被独占。
看线程状态是否长时间为 RUNNABLE
死循环线程不会进入 BLOCKED、WAITING 或 TIMED_WAITING 状态，堆栈里通常看不到锁等待或条件等待的调用（如 Object.wait()、LockSupport.park()）。用 jstack <pid></pid> 抓取线程快照后，重点筛选出状态为 RUNNABLE 的线程，并检查其堆栈末尾是否反复落在同一个方法或某几行代码上。
- 例如：堆栈末尾始终停在
MyService.processLoop() line 42，且该行是个while(true)或未设退出条件的for循环 - 再比如：反复调用
String.substring()+String.indexOf()构成的无效字符串查找逻辑，实际未推进索引
结合系统级线程 ID 定位真实热点
仅看 jstack 不够直观，需联动操作系统确认哪个线程真正在“狂转”：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 用
top -H -p <java_pid></java_pid>查出 CPU 使用率最高的线程（显示为 LWP，即轻量级进程 ID） - 将该十进制 TID 转为十六进制：
printf "%x\n" <tident></tident> - 在 jstack 日志中搜索这个十六进制值，就能精准定位到对应线程的完整堆栈
注意区分“假 RUNNABLE”和“真死循环”
不是所有 RUNNABLE 都是死循环。以下情况也表现为 RUNNABLE 但属于正常行为：
立即学习“Java免费学习笔记（深入）”；
- 密集计算：如图像压缩、加解密、大数组排序——这类任务本就该占 CPU，关键是看是否合理、是否可优化
- IO 密集型线程在做本地文件读写（未触发系统调用阻塞前）也可能短暂处于 RUNNABLE
- 频繁 GC 导致的线程抖动（如 CMS 或 ZGC 的并发阶段），需配合
jstat -gc判断
用 Arthas 快速验证和追踪
比手动解析 jstack 更高效的方式是使用 Arthas 实时观测：
-
thread -n 3：列出 CPU 使用时间最多的 3 个线程 -
thread <id></id>：查看指定线程当前堆栈和运行时间 -
trace <class><method></method></class>：对疑似循环体方法做耗时追踪，若发现单次调用耗时极短但调用频次爆炸（如每秒数千次），基本可断定是失控循环
