主线程中使用 while + Thread.sleep 会导致界面冻结和 ANR，因 sleep 阻塞 UI 线程；应改用后台线程配合 volatile 标志、中断检查、超时控制及主线程回调机制来安全轮询。
为什么 while + Thread.sleep 容易导致线程假死或响应卡顿
直接在主线程（比如 Android 的 UI 线程或 Swing 的 Event Dispatch Thread）里写 while (condition) { Thread.sleep(1000); }，会导致整个界面冻结、按钮无响应、甚至 ANR。因为 Thread.sleep 是阻塞式调用，它不会释放当前线程的执行权，只是暂停，而 UI 线程被占着就干不了别的事。
正确做法是把轮询逻辑放到后台线程里，同时注意异常捕获和退出控制：
-
Thread.sleep必须包裹在try-catch(InterruptedException)中，否则编译不通过； - 轮询条件不能只靠
while (flag)，要配合volatile修饰的布尔变量，否则 JVM 可能因指令重排或缓存导致子线程永远看不到主控线程改写的值； - 别用
while (true)硬循环加break，容易漏掉中断响应——应优先检查Thread.currentThread().isInterrupted()。
怎么安全启动并停止一个带 sleep 的轮询线程
典型场景：等待某个远程资源就绪（如文件生成、API 返回状态为 "done"），每 2 秒查一次，最多等 30 秒。关键不是“怎么睡”，而是“怎么可控地启停”。
示例代码片段（Java）：
interrupt()
- Android：用
Handler(Looper.getMainLooper())或Activity.runOnUiThread()； - JavaFX：用
Platform.runLater()； - Swing：用
SwingUtilities.invokeLater()。
错误示范：new Thread(...).start() 里直接调 textView.setText("done") —— 这行代码一定崩溃。正确写法是在轮询线程里触发回调，再由回调包装一层 UI 线程调度。
真正麻烦的从来不是“怎么睡”，而是“睡醒之后在哪执行、谁来管超时、中断信号有没有被吃掉、结果怎么安全传回来”。这些细节漏掉一个，轮询就变成不可靠的定时炸弹。
