二者字节码几乎等价，但语义与可读性不同：while(true) 易被静态分析标记为风险，for(;;) 多见于老项目；Java 不支持 while(1)；复杂 break 逻辑优先用 while(true)，for(;;) 在嵌套中易误读。
Java 中 while(true) 和 for(;;) 的实际差异
二者在字节码层面几乎等价，JVM 都会编译成无条件跳转指令，但语义和可读性不同。while(true) 更易被静态分析工具标记为潜在风险点，而 for(;;) 在老项目或嵌入式风格代码里更常见。
- 别用
while(1)—— Java 不支持整数当布尔值，编译直接报错：incompatible types: int cannot be converted to boolean - 如果循环体里有
break且逻辑复杂，优先选while(true)，语义上“明确知道要靠内部条件退出” -
for(;;)在多层嵌套中容易被误读成“漏写了循环变量”，尤其和for(int i = 0; i 混排时
IDEA / Eclipse 下定位死循环的实操技巧
不是靠猜，而是利用调试器的「线程暂停快照」能力。死循环通常表现为某个线程 CPU 占用持续 100%，且堆栈始终停在同一个方法内。
- 在疑似死循环的方法入口处打条件断点，比如：
Thread.currentThread().getName().contains("worker")，避免主线程干扰 - 运行后点「Pause Program」，看 Debug 窗口的 Threads 标签页——找状态为
RUNNABLE且堆栈深度极浅（比如只有 2–3 层）的线程 - 重点关注
at java.base/java.lang.Thread.sleep(Native Method)是否缺失：如果本该有的阻塞调用被删了或包错了，就极易形成空转
常见的“伪死循环”陷阱：看似没出口，其实卡在 I/O 或锁上
很多所谓“死循环”根本不是循环逻辑问题，而是线程被外部资源卡住，表现为循环体没执行完就挂起，但表象和死循环一模一样。
-
socket.read()在阻塞模式下可能永远不返回，看起来像卡在while里，实际是线程在WAITING状态 -
synchronized块里调用外部服务，而那个服务超时未设——锁一直不释放，后续循环迭代进不去 - 使用
ConcurrentHashMap的computeIfAbsent时，计算函数内部又去 get 同一把 key，触发隐式递归和死锁
用 JFR 或 jstack 快速验证是否真死循环
本地调试搞不定时，就得看运行时线程行为。关键不是看代码有没有 while(true)，而是看线程是否真在反复执行同一段字节码。
立即学习“Java免费学习笔记（深入）”；
- 用
jstack -l <pid></pid>抓线程快照，搜java.lang.Thread.State: RUNNABLE，再看其堆栈最后一行是不是总在同一个.java行号上 - 开启 JFR（Java Flight Recorder）：加 JVM 参数
-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr，然后用 JDK 自带的JDK Mission Control打开，筛选「Thread Allocation」和「Monitor Blocked」事件 - 注意：GC 频繁也可能让线程长时间停在
Object.wait()，这不是死循环，但表现类似——得结合 GC 日志一起看
