Java项目死循环不会抛出专门异常，而是表现为CPU飙升、线程卡死、响应超时或OOM；需通过top/jstack、监控指标、异常日志快速定位，并重点检查while(true)、flag未更新、for边界错误、递归无终止及对象持续创建等场景。
Java项目出现死循环，通常不会直接抛出“死循环异常”（Java中没有这种内置异常），而是表现为CPU飙升、线程卡死、响应超时或OOM（如栈溢出StackOverflowError、堆内存耗尽）。关键不是等它“报错”，而是要快速定位、中断并修复。
一、快速识别是否真有死循环
别只看日志——很多死循环根本没日志输出。重点观察：
- 进程CPU持续接近100%：用top -H -p [pid]查高占用线程ID，再用jstack [pid] | grep -A 20 [tid_in_hex]定位具体线程栈
- HTTP请求长时间无响应：配合监控（如Prometheus+Grafana）看某接口P99延迟突增、线程池活跃数打满
- 频繁出现StackOverflowError：说明是递归型死循环，堆栈深度无限增长
- Full GC频繁但内存不降：可能是循环中不断创建对象（如StringBuilder反复append未清空）
二、常见死循环场景与修复要点
多数死循环源于逻辑疏漏，不是语法错误。盯住这几类代码：
- while(true) 或 while(flag) 但 flag 永远不更新：检查break条件是否被异常跳过、是否在多线程下被覆盖、是否写成== false却忘了初始值为true
- for循环边界失控：比如for(int i=0; i ——size越变越大，i永远追不上
- 浮点数做循环条件：如for(double d = 0.0; d != 1.0; d += 0.1)，因精度问题d可能永远≠1.0，改用int计数或
- 并发修改导致条件失效：多个线程操作同一共享变量且无同步，建议用AtomicBoolean或加锁，或改用阻塞队列+poll(timeout)替代轮询
三、预防和调试技巧
靠事后排查成本太高，开发阶段就要设防：
立即学习“Java免费学习笔记（深入）”；
- 所有while循环必须有明确退出路径，并在注释中标明退出条件；复杂逻辑建议加最大迭代次数保护（如int maxLoop = 10000; while(condition && count++ ）
- 本地调试时开启JVM参数：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps辅助判断是否卡在GC；用IDE的“suspend on breakpoint”功能在可疑循环入口打断点，观察变量变化
- 单元测试覆盖边界情况：尤其测试空集合、单元素、超大数据量下的循环行为；用@Timeout（JUnit 5）防止测试本身卡死
- 上线后加轻量级循环监控：例如在关键while内每N次迭代记录一次traceId+当前状态，通过日志采样发现异常长循环
四、线上紧急止损方法
服务已卡死？先保可用，再查根因：
- 立即用jstack [pid] > thread.log保存现场，避免重启丢失证据
- 若确认是某接口引发，通过网关限流或熔断临时隔离该路径
- 对非核心后台线程，可考虑用Thread.interrupt()尝试唤醒（前提是循环内检查了Thread.currentThread().isInterrupted()）
- 终极手段：修改JVM启动参数加入-XX:+UseParallelGC -XX:MaxGCPauseMillis=200降低GC停顿影响，争取排查时间
基本上就这些。死循环不是玄学问题，本质是条件控制失效。养成“每次写循环都自问一遍：它一定能停吗？”的习惯，比任何工具都管用。
