和wait()区别，不止锁释放，底层原理与实战)
昨天面了个三年经验的候选人问到他sleep()和wait()的区别背得倒挺溜——sleep是Thread的方法wait是Object的方法sleep不释放锁wait释放锁完了。我再追问一句那面试官问这个问题到底想考什么他愣了一下。这个场景我见的太多了。说实话这道题如果只背到释放不释放锁这一层在面试官眼里和三年前刚培训出来的初级没什么区别。今天把这道经典题彻底拆开从底层原理到面试追问、再到实战中的选型和常见坑一次讲清楚。1. 从一个面试现场说起为什么这道题年年必问这道题在Java面试里出现的频率大概和HashMap原理一个级别。它考的不是你记没记住答案而是测试你对多线程核心机制——同步、锁、线程状态流转、线程间通信——的理解深度。很多候选人回答的时候习惯先背一条区别列表但这恰恰是面试官最头疼的答法。因为列表背下来容易但一旦换个问法就露馅。比如这样几个追问sleep(0)有意义吗为什么wait()必须在synchronized代码块里调用而sleep()不用wait()和sleep()都被中断会怎样产消模型中为什么用wait/notify而不是sleep轮询这些问题一句释放不释放锁是答不上的。所以我在下文里不只是讲区别更要把这两个方法各自的设计目的讲明白——它们是两套完全不同的机制只是恰好都叫让线程暂停一下而已。先给一句话定调sleep()是线程的自我暂停wait()是线程间的协作通信。后面的所有细节都是对这句话的展开。2. sleep()不释放锁的暂停键2.1 源码与底层行为Thread.sleep(long millis)是一个静态本地方法它让当前正在执行的线程注意不是某个线程对象进入TIMED_WAITING状态睡眠指定毫秒数后自动恢复。这里第一个容易踩的认知误区在于Thread.sleep()虽然是静态方法但很多人会写thread.sleep(1000)这样调用。这在语法上不报错但效果完全等同于Thread.sleep(1000)——因为静态方法不依赖实例编译器真正执行的是Thread.sleep(1000)和那个thread对象没关系更不可能让thread这个引用指向的线程去睡觉。public class SleepDemo { public static void main(String[] args) throws InterruptedException { Runnable task () - { synchronized (SleepDemo.class) { System.out.println(Thread.currentThread().getName() 进入同步块准备 sleep); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread().getName() sleep 结束离开同步块); } }; Thread t1 new Thread(task, 线程A); Thread t2 new Thread(task, 线程B); t1.start(); Thread.sleep(100); // 保证 t1 先拿到锁 t2.start(); } }运行结果线程A先输出进入同步块并准备sleep然后3秒内线程B一直在blocked状态等待锁线程A sleep结束、释放锁之后线程B才进入。这就是关键结论sleep()期间持有监视器锁不释放。哪怕线程B已经就绪也只能干等。提示sleep()不会释放任何锁——不只是synchronized锁包括ReentrantLock等显式锁也一样不释放。它只是纯粹地把CPU让出去但持有资源不放手。2.2 sleep的场景与设计意图sleep()在源码注释里写得很明白它存在的意义是让出CPU时间片给其他线程而不是用来协调线程间的先后顺序。所以它的典型应用场景一般是模拟耗时操作比如测试慢接口、模拟网络延迟、限流测试。控制轮询节奏比如某个后台线程每隔5秒检查一次配置是否更新。给某个操作等待的时间窗口比如等待外部资源就绪后再次尝试。但注意用sleep做线程间顺序协调是最常见的错误用法。很多人刚学多线程时都有过这种代码// 错误示范用 sleep 等待另一个线程执行完 threadA.start(); Thread.sleep(1000); // 猜测线程A大概1秒能跑完结果它跑了2秒 threadB.start(); // 此时线程B的执行依赖线程A的结果但已经被破坏这种猜时间的做法在复杂环境下必然出问题。机器负载高、GC停顿、调度器切换多了时间窗口就不可靠。正确的做法应该是用join()、Future、CountDownLatch这类机制而不是sleep。这也引出一个隐含考点join()底层其实也是用wait实现的而不是sleep——它需要在条件满足时被唤醒而不是死等一个固定的时间。3. wait()释放锁的通信枢纽3.1 监视器与等待集Object.wait()是实例方法它的语义是让当前线程进入该对象的等待集Wait Set并释放该对象的监视器锁直到其他线程调用同一个对象的notify()或notifyAll()将其唤醒。这里有几个理解重点。第一wait()释放的是这个对象的锁。如果线程持有多个对象的锁调用objA.wait()时只有objA的锁会被释放其他锁都还继续持有。这是很多人没注意到的细节。第二wait()必须和synchronized配合使用。原因后面专门讲但这里先记住没有监视器锁的线程调用wait()会立刻抛IllegalMonitorStateException。第三调用wait()时线程从RUNNABLE进入WAITING状态无参数的wait或TIMED_WAITING状态wait(long timeout)。没有参数时只能靠notify唤醒有时间参数时超时到点也会自动苏醒并重新竞争锁。public class WaitDemo { private static final Object lock new Object(); private static boolean condition false; public static void main(String[] args) throws InterruptedException { Thread waiter new Thread(() - { synchronized (lock) { System.out.println(等待线程进入同步块条件不满足调用 wait); try { while (!condition) { lock.wait(); // 释放锁等待通知 } System.out.println(等待线程被唤醒条件满足继续执行); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }, 等待线程); Thread notifier new Thread(() - { synchronized (lock) { System.out.println(通知线程进入同步块修改条件notifyAll); condition true; lock.notifyAll(); // 唤醒等待线程 } }, 通知线程); waiter.start(); Thread.sleep(100); // 确保 waiter 先进入 wait notifier.start(); } }这里有个极其重要的细节notifier必须先进入同步块拿到同一个lock的锁然后调用notifyAll之后退出同步块释放锁waiter才能真正从wait()返回并继续执行。也就是说wait()的唤醒不是立刻执行而是被唤醒 - 重新参与锁竞争 - 拿到锁 - 从wait()处返回。这中间的锁竞争可能让唤醒变成假唤醒后又阻塞也正因如此wait的标准写法一定是while(condition)循环而非if(condition)。3.2 wait/notify的协作模型wait()设计出来就是为了跨线程通信。生产者和消费者模型是最经典的解释消费者发现队列为空调用queue.wait()——释放锁并睡眠把CPU让给生产者生产者往队列里放了一个数据调用queue.notifyAll()——告诉消费者有货了消费者被唤醒重新拿到锁继续消费。public class ProducerConsumer { private final QueueString queue new LinkedList(); private final int CAPACITY 5; public synchronized void produce(String item) throws InterruptedException { while (queue.size() CAPACITY) { wait(); // 队列满了等待消费者消费 } queue.offer(item); System.out.println(生产: item 当前队列: queue.size()); notifyAll(); } public synchronized String consume() throws InterruptedException { while (queue.isEmpty()) { wait(); // 队列空了等待生产者生产 } String item queue.poll(); System.out.println(消费: item 当前队列: queue.size()); notifyAll(); return item; } }注意这个例子中produce()和consume()都是synchronized方法它们的监视器锁都是this对象所以wait()和notifyAll()无须显式指定锁对象。如果你用的是synchronized代码块则必须写成lock.wait()和lock.notifyAll()且必须与进入代码块时锁的对象保持一致——不一致立刻抛异常。4. 核心差异对比能把锁这件事讲透才是真懂4.1 对比表格先给一个完整的对比表格后端面试时能在白板上画出这个已经比大多数人强了。对比维度sleep()wait()归属Thread类的静态方法Object类的实例方法是否释放锁不释放任何锁释放当前对象的监视器锁调用前置条件无任何地方都可调用必须在synchronized代码块/方法内否则抛IllegalMonitorStateException唤醒方式时间到了自动苏醒依赖notify/notifyAll唤醒或wait(timeout)超时自动苏醒线程进入状态TIMED_WAITINGWAITING无参wait或TIMED_WAITING有参本质用途线程自我暂停让出CPU线程间通信实现等待/通知机制对锁竞争的影响持有锁继续阻塞其他线程释放锁让其他线程有机会进入临界区可中断性可被interrupt打断并抛InterruptedException可被interrupt打断并抛InterruptedException是否属于Object类的方法否是关键点凡是Object类的方法意味着每个对象都有。任何Java对象都可以作为锁因此任何对象都可以调用wait/notify这就是管程模型在Java中的体现——每个对象天生自带一个监视器。4.2 为什么wait()必须在synchronized里而sleep()不用这个问题是面试官最爱深挖的需要从语义和底层两个层面理解。语义层面wait()的本意是在条件不满足时让线程等待并释放锁让别人去改变条件。如果调用wait()时线程根本不持有锁那释放锁无从谈起也无法保证判断条件与等待之间的原子性。设想一下如果不在同步块里一个线程先检查队列为空在它准备调用wait()的间隙另一个线程往队列里放入了数据并调用了notifyAll——但由于前面的线程还没进入wait状态这次通知就丢失了前面的线程则会永远等下去。把判断条件、写入wait、释放锁放进同一个synchronized临界区才能确保等之前先检查检查结果与等待动作不被打断。底层层面JVM内的每个对象都关联一个监视器Monitor。wait()的底层操作是把当前线程放入该监视器的等待集合WaitSet并调用底层操作系统原语释放监视器。这整个过程只对已持有该监视器的线程是合法操作。HotSpot虚拟机中Object.wait()的native实现第一步就是检查线程是否拥有当前对象的监视器——ObjectSynchronizer::wait会先做这个校验不通过直接抛出IllegalMonitorStateException。这个异常名的字面意思就是你调用了wait但你的线程状态根本不在合法的监视器持有状态。反过来看sleep()为什么不用在同步块里sleep()不涉及锁的交互它只是把线程挂起指定时间。它不需要锁因为它压根不准备和别的线程协作也不需要原子地检查条件睡眠。所以Thread这类静态工具方法在任何上下文都能调用。这个追问的完整回答应该是wait()的语义决定了它必须与synchronized配合确保检查条件到释放锁的过程是原子操作避免通知丢失sleep()只是个定时暂停工具不依赖锁状态所以不需要放在同步块里。4.3 谁该被哪个方法拦住锁竞争差异的实战含义sleep()持锁睡眠对锁竞争的影响是阻碍性的线程明明不干活却还占着锁其他线程只能阻塞等待。这在生产代码里很危险——如果持锁线程sleep 30秒所有争这把锁的线程全部卡死可能引发线程池饱和、请求超时堆积甚至线上事故。wait()则完全不同它是配合性的——线程愿意放弃锁通知其他线程你可以进来改条件。这样锁的利用率是最高效的。举一个我实际遇到过的案例。某次线上服务偶发响应缓慢排查发现代码里有个分布式锁的刷新线程在持有锁的同步块里做了Thread.sleep(2000)。表面看只是隔两秒刷新一次租期但这2秒内所有需要读取同一把锁保护的资源的请求全被堵住。改成wait/notify的模型后锁的持有时间缩短到几乎只有状态更新的那几毫秒响应时间立刻恢复平稳。这个案例说明一个很重要的开发原则锁临界区内能不用sleep就不用sleep如果确实需要等待某个条件变化再去执行优先考虑wait/notify或Lock的condition机制而不是盲目sleep。5. 面试官的连环追问从这里看出真懂和背过5.1 虚假唤醒为什么必须在while循环里wait这是wait()使用中最容易翻车的坑也是面试官很爱问的进阶题。先看这段代码// 错误写法用 if 而不是 while synchronized (lock) { if (!condition) { lock.wait(); } // 执行依赖于 condition 为 true 的逻辑 }问题在于**wait()被唤醒并重新拿到锁之后条件可能已经被别的线程再次改掉了。**比如产消模型中两个消费者都被唤醒其中一个消费掉了唯一的数据另一个拿到锁从wait()返回后队列已经空了但它的代码还继续往下执行消费逻辑——轻则空转重则空指针。这就叫虚假唤醒spurious wakeup即使只用notifyAll也依然存在。更严谨地说即使没有操作系统层面的虚假唤醒被唤醒后与其他线程竞争锁、在等待期间条件已经被改变这一点本身就足以要求我们必须用while循环重新检查条件。所以标准写法必须是这样synchronized (lock) { while (!condition) { // 循环检查而不是 if lock.wait(); } // 到这里才真正满足条件 }在《Effective Java》和Java官方文档中都明确建议wait()必须放在while循环中。这也是开发规范里少有的官方强制要求。候选人如果能自己说出这一点面试官基本可以判定他真的写过多线程代码。5.2 wait()后的线程是WAITING还是BLOCKED这个问题经常被用来考察对线程状态机的理解。调用wait()后线程进入WAITING状态无参wait或TIMED_WAITING状态wait(timeout)。WAITING的特点是它不参与锁竞争、不占用CPU直到被notify或中断才会重新进入锁等待BLOCKED或RUNNABLE。而被notify唤醒之后、还在等待获取锁的那段时间线程才会进入BLOCKED状态。所以严格来说wait()之后的状态是WAITING唤醒后先变成BLOCKED如果锁还被占着拿到锁后才RUNNABLE。sleep()则直接进入TIMED_WAITINGsleep期间同样不占CPU但锁没释放。这两者的状态流转也是面试常考的变体sleep和wait(0)的状态不同、Thread.yield()的状态不同——yield还在RUNNABLE只是让出当前CPU调度机会。5.3 能拿notify/notifyAll对比做文章吗sleep()没有唤醒概念时间到自动醒来。面试官一般会顺着notify/notifyAll往下问为什么用notifyAll而不是notify这里有个经典结论notify()是随机唤醒一个线程notifyAll()是唤醒所有等待线程。在只有一个等待者时两者等价但当有多个生产者和多个消费者时只用notify()可能造成信号丢失或线程饥饿。举个例子两个消费者都因为队列空而wait了一个生产者放了一个数据后调用notify()结果唤醒的还是消费者A消费者A消费完了队列又空了消费者B还在永久等待。即使生产者随后再次放数据并notify如果这次恰好又唤醒AB可能连续多次躺枪。相比之下notifyAll唤醒全部让所有线程重新检查条件安全性高得多。所以无特殊理由一律推荐notifyAll。5.4 JDK 5之后的替代品Condition有了synchronized/wait/notify之后JUC包里的ReentrantLock和Condition也值得提。Condition的await()和signal()/signalAll()等价于wait/notify但功能更强——条件的粒度更细可以一个锁下面挂多个等待队列。public class ConditionDemo { private final ReentrantLock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); private final Condition notEmpty lock.newCondition(); private final QueueString queue new LinkedList(); private final int capacity 5; public void produce(String item) throws InterruptedException { lock.lock(); try { while (queue.size() capacity) { notFull.await(); // 生产者在队列满条件上等待 } queue.offer(item); notEmpty.signalAll(); // 唤醒队列非空条件上的等待者 } finally { lock.unlock(); } } public String consume() throws InterruptedException { lock.lock(); try { while (queue.isEmpty()) { notEmpty.await(); } String item queue.poll(); notFull.signalAll(); return item; } finally { lock.unlock(); } } }Condition能将队列满和队列空两种等待分离开避免synchronized模型中所有线程都阻塞在同一个等待集上造成的无效唤醒。面试时提到这一点直接拉开与其他候选人的差距。6. 实战项目中的选型与排坑经验6.1 什么时候用sleep什么时候用wait很多初学者写完产消模型之后顺手就把sleep当延时工具塞进去了。下面这个表是我在实际帮助团队review代码时经常提到的最小选型标准场景推荐方案不推荐的方案周期性执行定时拉取、心跳上报、批量轮询ScheduledExecutorService或代码内用sleep控制节奏wait/notify等待某个条件满足后再继续消息到达、任务完成、队列非空wait/notify、Condition、CompletableFuture、BlockingQueuesleep轮询模拟延迟、限速、测试延时场景sleepwait需要等待另一线程执行完毕join()、CountDownLatch、Future.get()sleep猜时间分布式场景跨进程等待消息队列、ZooKeeper、Redis的阻塞读本地wait/notify不同JVM不共享监视器这里补充一点wait/notify的适用范围仅限于同一个JVM内的线程间通信。跨进程场景根本不会用到它这也是为什么生产上用得更多的是BlockingQueue、CompletableFuture——它们底层确实用了锁和条件等待但对外暴露的API友好得多。6.2 我踩过的三个坑坑一try/finally中丢失notify导致线程池永久阻塞。某个内部任务调度系统用wait实现任务完成后唤醒下一个任务但有一次某个任务抛异常后直接return跳过了finally中的notify结果后续线程全部卡在wait上整个任务链挂了半个小时。修复方案很简单notify/signal放在finally块或者用try-with-resources闭包管理。这里建议所有用到wait的生产代码唤醒动作一定要确保执行。坑二用sleep在锁内等外部接口返回。有同事在synchronized块里调外部HTTP接口还加了个Thread.sleep(500)防止频率太高结果接口响应慢的时候这个锁被hold了好几分钟所有请求线程全部堆积。后面改为在锁外等待把HTTP调用从同步块里挪出来只把需要保护的共享数据结构更新放在临界区。这个教训是锁的粒度越小越好sleep这种纯粹浪费时间的操作绝不进临界区。坑三对lock.wait(timeout)的超时唤醒抱有错误期待。wait(3000)确实会在3秒之后自动醒来但醒来后它还会继续参与锁竞争而不是3秒后立刻执行完wait()返回。如果锁一直被别人占着它可能3秒后依然处于BLOCKED状态还要再等锁释放。这一点在设置超时参数时必须清楚避免以为timeout是硬性截止时间。6.3 如何自查一个简单的是否真的懂清单问自己几个问题能答上来基本算过关能不能说出wait()必须在synchronized里的两个层面原因知不知道wait(1000)和sleep(1000)在锁竞争下的行为差异写不写得出while(condition)而不是if(condition)知不知道notify()和notifyAll()在多消费者单生产者下哪个安全能不能说出WAITING、BLOCKED、TIMED_WAITING之间的状态流转关系知不知道在ReentrantLock中与wait/notify等价的是哪两个方法7. 写在最后一道题背后的一整套体系回看这道题它看起来是两个方法的区别实际考察的是整个Java并发体系的地基锁、同步、线程状态、线程间通信、锁竞争、JMM内存可见性一个都不能少。把这些串起来之后你在面试中不仅能把这道题答漂亮还能顺手结合Condition、BlockingQueue、CompletableFuture等现代工具讲出自己的实战理解让面试官真正觉得你是一个写过并发代码的工程师而不是背了一晚上八股文的求职者。最后再分享一条我总结的经验以上这些面试题很多人是看的、背的、不是写的。我强烈建议你花一个下午自己手写一遍生产者-消费者——分别用synchronized/wait/notify版本、ReentrantLock/Condition版本、BlockingQueue版本实现一遍然后把三个版本放一起对比。写完之后你会发现sleep和wait的区别你会在任何面试场景下都能张口就来而且顺着这套代码你还能自然展开到锁升级、公平锁、队列有界性、线程池拒绝策略这些更深的面试话题。这才是这一道题最值钱的部分。
