while(true)是Java中编写死循环的标准写法，开销最小且语义明确；退出必须依赖break、return或异常；需配合Thread.interrupted()实现响应式中断，避免在GUI主线程中使用。
Java里写死循环，while(true) 是最直接的方式
它不依赖外部变量或条件计算，CPU 每次进循环只做一次布尔判断（恒为 true），开销极小，也最符合“死循环”的语义。别用 while(1) 或 while(!false) —— Java 不接受非布尔字面量作条件，编译直接报错：incompatible types: int cannot be converted to boolean。
常见错误是误以为 while(condition == true) 更安全，其实多一次冗余比较，且当 condition 是包装类（如 Boolean）时可能触发空指针。
-
while(true)是标准写法，JVM 会做常量折叠优化，实际性能和手写跳转指令几乎一致 - 避免在条件中调用方法（如
while(shouldKeepRunning())），哪怕它返回true，也会每次重复调用，增加栈帧和潜在副作用 - IDE（如 IntelliJ）对
while(true)有专门检查，可配成警告而非错误，因为确实常用于服务器主循环、事件轮询等场景
退出死循环只能靠 break、return 或异常
没有“自然结束条件”，所以不能靠条件表达式退出。想中途跳出，必须显式控制流转移。
典型错误是试图用 condition = false 然后期待循环自动终止——这在 while(true) 下完全无效，变量改了也不影响下一轮的 true 判断。
立即学习“Java免费学习笔记（深入）”；
-
break退出当前循环，适合单层死循环；嵌套时需配合标签（outer: while(true) { ... break outer; }） -
return直接结束所在方法，适合死循环封装在独立方法中（比如void serve()里跑网络请求） - 抛异常（如
throw new ShutdownSignal()）也能跳出，但属于非常规手段，会干扰调用栈，且异常处理成本比break高一到两个数量级
用 Thread.interrupted() 做响应式退出更可靠
纯 while(true) 容易让线程无法被中断，尤其在阻塞操作（如 Thread.sleep()、Object.wait()、IO 读取）中，interrupt() 调用可能被忽略或仅设中断状态位。
正确做法是把中断检查作为循环守卫，而不是等阻塞结束后再判断。
- 在循环开头加
if (Thread.interrupted()) break;，确保每次迭代都响应中断 - 如果循环体内有阻塞调用，优先选带中断支持的版本（如
LockSupport.park()而非wait()，BlockingQueue.poll(timeout)而非take()） - 注意
Thread.interrupted()是静态方法，会清除中断状态；若需保留状态供后续逻辑使用，改用Thread.currentThread().isInterrupted()
别在 GUI 或 Android 主线程里写 while(true)
这类环境要求主线程持续响应事件分发（如 Swing 的 Event Dispatch Thread、Android 的 Main Looper），一旦进入无退出的 while(true)，界面立刻冻结，系统判定为 ANR（Application Not Responding）。
有人试图加 Thread.sleep(10) “缓解”，但这只是让卡顿从“完全无响应”变成“间歇性卡顿”，并未解决根本问题。
- GUI 场景该用定时器（
SwingTimer、Handler.postDelayed()）或事件监听，而非轮询 - 后台任务必须扔到子线程（
ExecutorService、AsyncTask已废弃，用Coroutine或CompletableFuture） - 即使子线程用了
while(true)，也必须包含明确的退出路径和中断响应，否则进程退出时线程可能无法被回收
真正难的不是写出死循环，而是让它的生命周期和外部控制信号对齐——中断状态、共享变量可见性、阻塞点的可打断性，这三个地方出问题，调试起来比写循环本身花十倍时间。
