wait()会释放锁，sleep()不会；wait()必须在synchronized块中调用并释放对象锁，使其他线程可进入同步代码块，而sleep()是thread静态方法，不释放锁，仅暂停当前线程。
关键就一点：wait() 会释放当前持有的对象锁，sleep() 不会。
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 块
锁释放与否，直接决定了是否允许协作、是否造成不必要的串行等待。这是设计线程通信逻辑时不可绕过的底层事实。
