Thread.sleep() 不释放 synchronized 锁，因其仅挂起线程而不涉及锁操作；错误地在同步块内调用会导致其他线程阻塞，应最小化锁范围或改用 wait()/ScheduledExecutorService。
Thread.sleep() 暂停线程时，不会释放任何已持有的对象锁（即 synchronized 锁），这是 Java 多线程中一条关键且易错的“红线”。牢记它的核心在于理解“sleep 是线程自身的暂停，不是让出锁的协作行为”。
为什么 sleep 不释放锁？本质是“挂起而非放弃”
Thread.sleep() 的作用是让当前线程进入 TIMED_WAITING 状态，由操作系统或 JVM 暂停其执行一段时间。它不涉及锁的申请、释放或竞争逻辑——既不是 wait() 那样的锁条件等待，也不是 unlock() 那样的显式释放。只要线程还持有 synchronized 块/方法的监视器（monitor），该锁就一直被占着。
- 哪怕睡 10 秒，其他线程仍无法进入同一把 synchronized 锁保护的临界区
- 如果在 synchronized(this) 内调用 sleep()，this 对象的锁全程被独占
- 这和 Object.wait() 有本质区别：wait() 必须在 synchronized 中调用，且会立即释放锁并进入 WAITING 状态
典型踩坑场景：误把 sleep 当作“让出 CPU + 让出锁”
新手常以为“线程睡了，别人就能进临界区”，结果导致严重阻塞：
- 错误写法：synchronized (lock) { doSomething(); Thread.sleep(1000); } → 其他线程卡在 lock 外干等 1 秒
- 更隐蔽的错误：在 synchronized 方法里调用第三方可能耗时的方法（如日志、网络），中间夹着 sleep，锁持有时间远超预期
- 后果：吞吐量骤降、线程饥饿、甚至死锁风险（尤其当多个锁嵌套时）
怎么避免？三招守住这条红线
- 锁的范围最小化：只把真正需要互斥的代码包进 synchronized，把 sleep()、I/O、计算等非临界操作移出来
- 换用更合适的等待机制：需要“释放锁 + 等待条件”时，用 Object.wait() / Condition.await()；需要定时调度，用 ScheduledExecutorService 而非在锁内 sleep()
- 加日志或监控验证：在 synchronized 块前后打时间戳日志，观察实际持锁时长是否异常；用 jstack 查看线程堆栈，确认 BLOCKED 线程是否正卡在某把锁上
一句话口诀记牢
“sleep 是线程打盹，不是交钥匙；锁还在你手上，别人进不来。” 只要没退出 synchronized 作用域，锁就纹丝不动。
