thread.sleep()不释放锁、中断状态被捕获后自动清除、精度不可靠且嵌套使用易致死循环，正确做法是恢复中断状态、避免同步块内休眠、改用条件等待或协作式机制。
中断状态会被自动清除
在catch块里调用Thread.sleep()前，必须意识到：一旦捕获到InterruptedException，线程的中断状态已被JVM自动置为false。这意味着后续调用Thread.interrupted()会返回false，哪怕你刚被中断过。如果业务逻辑依赖中断信号（比如退出循环），直接忽略或仅打印日志会导致线程继续执行，失去响应能力。
正确做法是在catch中立即恢复中断状态：
- 调用Thread.currentThread().interrupt()重置标志
- 再根据需要决定是否break、return或重新抛出异常
嵌套sleep可能引发死循环
常见错误是在while循环的try块里调用sleep，但异常发生在sleep之前（比如网络请求或JSON解析失败），导致sleep被跳过。下一轮循环立刻重试，没有延迟，形成高频空转甚至CPU打满。
例如：
- try { doWork(); Thread.sleep(5000); } —— 若doWork()抛异常，sleep不执行
- catch块若没处理好，循环立即重启，相当于“零延迟重试”
解决方式：把sleep放在finally块末尾，或确保所有路径都包含延时逻辑。
锁不会释放，慎用于同步上下文
Thread.sleep()从不释放synchronized锁或ReentrantLock。如果在synchronized方法或代码块里调用它，其他线程仍会被阻塞等待该锁，休眠期等于“锁独占期”。这常被误当成“让出资源”，实际加剧竞争。
典型反模式：
- synchronized void refresh() { getToken(); Thread.sleep(60000); }
- 结果：整个刷新过程锁住60秒，其他线程全卡住
应改为先释放锁再sleep，或换用Condition.await()等协作式等待。
精度不可靠，别依赖精确计时
sleep(10)不保证停10毫秒——受系统时钟分辨率（Windows常为15.6ms）、调度延迟、GC暂停影响，实际可能停10–50ms。高频轮询中用sleep(1)基本无效，还增加调度开销。
替代建议：
- 轮询+轻量等待：用Thread.onSpinWait()（Java 9+）配合volatile变量
- 条件触发：优先选CountDownLatch、CompletableFuture或ScheduledExecutorService
- 微秒级控制：考虑LockSupport.parkNanos()，但需配套unpark
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
