thread.sleep()阻塞当前线程但不释放锁，使线程进入timed_waiting状态；必须处理interruptedexception，推荐捕获后恢复中断标志；纳秒参数仅作精度提示，实际精度受限于系统；不适用于需让出锁的协作场景。
Thread.sleep() 会阻塞当前线程，但不会释放锁
调用 Thread.sleep() 会让当前线程进入 TIMED_WAITING 状态，暂停指定毫秒数，期间它既不占用 CPU，也不让出已持有的 synchronized 锁或 ReentrantLock。这点和 Object.wait() 不同——后者必须在同步块内调用，且会释放锁。
常见误用场景：在 synchronized 方法里调用 sleep()，以为能“让其他线程进来”，结果别的线程还在等锁，根本进不来。
- 只适用于“我就是想停一下，不关心别人能不能抢资源”的简单延时场景
- 不能替代线程协作机制（如
wait/notify、Condition） - 若需“暂停 + 让出锁”，应改用
LockSupport.parkNanos()配合条件变量
必须处理 InterruptedException，否则编译不通过
Thread.sleep(long) 和 Thread.sleep(long, int) 都声明抛出 InterruptedException，这是受检异常（checked exception），不捕获或声明就过不了编译。
典型错误写法：Thread.sleep(1000); 直接报错 “unreported exception InterruptedException”。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 推荐做法：显式捕获并恢复中断状态，例如：
try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断标志 // 或根据业务决定是否立即返回/抛出 } - 不要用空的
catch块吞掉异常，这会丢失线程中断信号 - 如果当前方法本身可以抛出异常，也可直接加
throws InterruptedException向上委托
参数单位是毫秒，纳秒部分只作精度提示，不保证实际精度
Thread.sleep(500, 500000) 表示“休眠 500 毫秒 + 500000 纳秒”，即总共约 500.5 毫秒。但底层依赖操作系统定时器，实际暂停时间可能略长（尤其在高负载或虚拟机环境中）。
注意：纳秒参数范围必须是 0–999999，超出会抛 IllegalArgumentException。
- 常用组合只有
Thread.sleep(1000)（1 秒）、Thread.sleep(10)（10 毫秒）这类整数毫秒值 - 不要指望靠纳秒参数实现微秒级精确控制；需要更高精度请考虑
LockSupport.parkNanos()或专用调度库 - 在 Linux 上，JVM 通常基于
nanosleep()实现，但最小分辨率常为 10–15ms
在 ExecutorService 中直接 sleep 可能导致线程池资源浪费
如果在 Runnable 或 Callable 中调用 Thread.sleep()，而该任务正运行在固定大小的线程池（如 Executors.newFixedThreadPool(3)）中，那么这 1 个线程就被占着不动，无法处理新任务。
这不是 bug，而是设计使然：线程池线程就是用来执行任务的，sleep 就是任务的一部分。
- 若需延迟执行，优先用
ScheduledExecutorService.schedule()，它不阻塞工作线程 - 若必须在任务中等待外部条件（如轮询），建议配合
Thread.yield()或指数退避，避免死等 - 长时间 sleep（如 >1 分钟）要格外谨慎，可能掩盖线程泄漏或调度失衡问题
InterruptedException 当成普通异常随便 catch，却忘了重置中断状态。一旦中断标志被清空，上层逻辑就再也收不到这个信号了。Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
