1. 面试必问：Java 中 sleep 和 wait 的深度解析
在 Java 并发编程面试中，关于 sleep() 和 wait() 的区别几乎是必考题。很多初级开发者只能说出"一个会休眠，一个会等待"这种浅层回答，这往往会让面试官对你的技术深度产生质疑。实际上，这道题考察的是你对 Java 线程模型、锁机制和线程通信的全面理解。
我作为面试官时，最希望听到的回答应该包含以下维度：
- 方法所属的类及其设计意图
- 对锁的影响（是否释放）
- 线程状态的变化
- 使用场景和最佳实践
- 底层实现原理
2. 核心区别解析
2.1 基础特性对比
先来看最基础的对比表格：
| 对比项 | sleep | wait |
|---|---|---|
| 所属类 | Thread 类的静态方法 | Object 类的实例方法 |
| 锁行为 | 不释放任何锁 | 释放当前持有的锁 |
| 调用位置 | 任意位置 | 必须在 synchronized 代码块中 |
| 唤醒机制 | 时间到自动唤醒 | 需要其他线程调用 notify/notifyAll |
| 线程状态 | TIMED_WAITING | WAITING |
| 异常处理 | 需要捕获 InterruptedException | 需要捕获 InterruptedException |
2.2 锁行为的本质区别
这是面试中最容易忽略但最重要的点。当线程调用 sleep() 时：
java复制synchronized(lock) {
Thread.sleep(1000); // 仍然持有lock
// 其他线程无法进入这个同步块
}
而 wait() 的调用：
java复制synchronized(lock) {
lock.wait(); // 立即释放lock
// 其他线程可以获取lock
}
这个区别直接影响了程序的并发性能。我曾经在一个高并发项目中见过错误使用 sleep() 导致性能瓶颈的案例：开发者在同步块内使用 sleep() 做延迟，结果导致所有线程串行执行，完全失去了并发优势。
2.3 状态转换机制
从线程状态机的角度看：
- sleep()：RUNNABLE → TIMED_WAITING → RUNNABLE
- wait()：RUNNABLE → WAITING → BLOCKED → RUNNABLE
这里有个关键点：被 notify() 唤醒的线程会先进入 BLOCKED 状态竞争锁，获取锁后才能继续执行。这解释了为什么 wait() 必须配合 synchronized 使用。
3. 底层原理深入
3.1 wait/notify 的监视器机制
每个 Java 对象都有一个内置的监视器锁（monitor），这个机制是通过 Object 类的三个方法实现的：
- wait(): 释放 monitor，线程进入等待集合
- notify(): 随机唤醒一个等待线程
- notifyAll(): 唤醒所有等待线程
这就是为什么这些方法定义在 Object 类中 - 因为它们与对象的内置锁直接相关。
3.2 sleep 的 OS 实现
Thread.sleep() 的底层是通过操作系统提供的线程调度实现的：
- 记录当前线程上下文
- 设置定时器中断
- 将线程移出就绪队列
- 时间到后重新加入就绪队列
值得注意的是，sleep() 的精度取决于操作系统调度器，不能保证精确睡眠指定时间。
4. 实战应用场景
4.1 适合使用 sleep 的场景
- 定时任务：比如轮询检查某个状态
java复制while(!condition) {
Thread.sleep(1000); // 每秒检查一次
}
- 速率限制：控制操作频率
java复制void processRequest(Request req) {
handle(req);
Thread.sleep(100); // QPS控制在10
}
- 模拟延迟：测试环境模拟网络延迟
4.2 适合使用 wait 的场景
- 生产者-消费者模式：
java复制// 生产者
synchronized(queue) {
while(queue.isFull()) {
queue.wait();
}
queue.add(item);
queue.notifyAll();
}
// 消费者
synchronized(queue) {
while(queue.isEmpty()) {
queue.wait();
}
queue.take();
queue.notifyAll();
}
- 条件等待：等待某个条件满足
java复制synchronized(lock) {
while(!condition) {
lock.wait();
}
// 条件满足后的处理
}
- 线程协作：多个线程按特定顺序执行
5. 常见误区与最佳实践
5.1 典型错误用法
- 不在同步块中使用 wait()
java复制// 错误示范！
public void doWait() {
obj.wait(); // 抛出IllegalMonitorStateException
}
- 使用 if 而不是 while 检查条件
java复制// 错误示范！
synchronized(lock) {
if(!condition) {
lock.wait(); // 可能虚假唤醒
}
}
- 混淆 sleep 和 wait 的锁行为
java复制synchronized(lock) {
Thread.sleep(1000); // 锁一直被占用
// 应该用 wait() 如果目的是等待条件变化
}
5.2 最佳实践建议
- 总是使用 while 循环检查条件，防止虚假唤醒
- 优先使用 java.util.concurrent 包中的高级工具类
- wait() 和 notify() 应该作为对象内部实现细节，不要暴露给外部
- 考虑使用显式锁（Lock）和条件变量（Condition）替代 synchronized + wait/notify
6. 面试深度扩展
当面试官问完基础区别后，通常会深入探讨以下问题：
6.1 为什么 wait() 需要在同步块中调用？
这涉及到 Java 内存模型（JMM）的 happens-before 规则。为了保证 wait() 前的修改对 notify() 后的代码可见，必须通过锁建立 happens-before 关系。否则可能出现：
- 条件检查时看到旧值
- 修改条件后通知丢失
6.2 sleep(0) 的特殊作用
Thread.sleep(0) 看似无意义，实际上它会提示调度器让出当前线程的剩余时间片。这在某些计算密集型任务中可以改善响应性。
6.3 虚假唤醒（Spurious Wakeup）问题
操作系统可能在没有 notify() 的情况下唤醒 wait() 的线程。这就是为什么条件检查必须用 while 而不是 if：
java复制synchronized(lock) {
while(!condition) { // 必须用while
lock.wait();
}
}
6.4 现代替代方案
在 Java 5+ 中，更推荐使用：
java复制Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
// 等待
lock.lock();
try {
while(!condition) {
condition.await();
}
} finally {
lock.unlock();
}
// 通知
lock.lock();
try {
condition.signalAll();
} finally {
lock.unlock();
}
这种方式更灵活，支持多个条件变量，且可中断。
7. 性能考量与实战经验
在实际项目中，关于线程等待有几个重要的性能经验：
-
sleep() 的精度问题：
- Windows 系统默认精度约 15ms
- Linux 系统默认精度约 1ms
- 如果需要更高精度，考虑使用 LockSupport.parkNanos()
-
notify() vs notifyAll()：
- notify() 更高效但容易死锁
- notifyAll() 更安全但可能引起"惊群效应"
- 根据场景谨慎选择
-
等待超时机制：
总是建议使用带超时的 wait()：java复制lock.wait(5000); // 最多等待5秒防止系统永久挂起
-
中断处理：
正确处理中断是健壮代码的关键：java复制try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 // 清理资源 }
8. 从 JVM 角度看实现
深入理解这些方法需要了解 JVM 的实现：
-
wait() 的 JVM 实现：
- 调用时检查当前线程是否是锁所有者
- 将线程加入对象的等待集合
- 释放锁并切换线程状态
- 被唤醒后重新竞争锁
-
sleep() 的 JVM 处理：
- 转换为 native 方法调用
- 通过操作系统调度实现
- 不涉及锁操作
-
内存可见性保证：
- wait() 调用前会刷新线程工作内存到主内存
- notify() 调用后会从主内存重新加载变量
这些底层细节解释了为什么必须遵守 wait/notify 的使用规则。