如何精确区分Object的wait()方法与Thread的sleep()方法在同步锁释放机制上的细微差别？

本文共计489个文字，预计阅读时间需要2分钟。

关键词就一点：

wait() 必须在 synchronized 块中调用，且会主动让出锁

调用 wait() 前，线程必须已经获取了某个对象的监视器锁（即已进入 synchronized(obj) 块）。一旦执行 wait()，线程立即释放该对象的锁，并进入该对象的等待队列。此时其他线程就能竞争并获得这个锁，执行对应的同步代码。

• 不释放锁，其他线程就无法进入同一把锁保护的 synchronized 块
• wait() 后线程处于 WAITING 状态，需靠 notify()/notifyAll() 唤醒
• 被唤醒后不会立刻执行，而是重新竞争锁；抢到锁后才从 wait() 返回继续往下走

sleep() 与锁完全无关，持有锁时调用也不释放

sleep() 是 Thread 的静态方法，只影响当前线程的调度状态。即使它出现在 synchronized 块内部，线程在睡眠期间依然牢牢占着锁，其他线程只能干等。

• 调用 sleep(1000) 后，线程进入 TIMED_WAITING 状态，但锁未释放
• 时间一到自动恢复为 RUNNABLE 状态，接着执行后续代码
• 也可被 interrupt() 中断，抛出 InterruptedException

一个典型对比场景

假设有两个线程操作同一个共享对象 obj：

• 线程 A 进入 synchronized(obj) 后调用 obj.wait() → 锁释放，A 挂起，B 可以进 synchronized(obj)
• 线程 A 进入 synchronized(obj) 后调用 Thread.sleep(1000) → 锁不放，B 被阻塞在 entry set，直到 A 睡醒并退出 synchronized 块

锁释放与否，直接决定了是否允许协作、是否造成不必要的串行等待。这是设计线程通信逻辑时不可绕过的底层事实。