在Java里sleep和wait有什么不同_Java线程阻塞机制对比说明

sleep是Thread静态方法，wait是Object实例方法；sleep不释放锁且可任意调用，wait必须在synchronized块内调用并释放锁，需配合notify/notifyAll唤醒，并用while循环防虚假唤醒。

sleep 是 Thread 的静态方法，wait 是 Object 的实例方法

这是最根本的差异，直接决定你能不能调用、在哪调用、要不要加锁。Thread.sleep() 属于线程自身行为，不依赖任何对象；而 obj.wait() 必须作用在某个具体对象上，且该对象必须是当前线程已持有的锁目标。

常见错误现象：wait() 被写在非 synchronized 块里，运行时抛出 IllegalMonitorStateException —— 不是语法错，是 JVM 在运行时检查到“你没拿锁就敢释放锁”，直接拒绝执行。

• Thread.sleep(1000) 可以出现在任意位置（但需处理 InterruptedException）
• lock.wait() 必须写在 synchronized(lock) { ... } 内部
• 想唤醒等待中的线程？只能用 lock.notify() 或 lock.notifyAll()，且同样必须在 synchronized(lock) 块中

sleep 不释放锁，wait 会释放锁

这个区别直接影响并发逻辑是否死锁或卡住。比如你在同步块里做耗时操作，又想让其他线程能进来干活，用 sleep 就白搭——锁还攥着，别人干瞪眼；而 wait 一调，锁立刻松手，别人就能进来了。

实操建议：别靠“休眠几秒”来模拟等待条件，那是反模式。例如生产者-消费者场景中，用 queue.wait() 等待队列非空，比 Thread.sleep(100) 轮询更高效、更安全。

立即学习“Java免费学习笔记（深入）”；

Amazon Nova

亚马逊云科技（AWS）推出的一系列生成式AI基础模型

下载

• 持有锁期间调用 Thread.sleep(5000) → 其他线程阻塞等待该锁，5 秒内无法进入临界区
• 持有锁期间调用 queue.wait(5000) → 锁立即释放，其他线程可操作 queue；5 秒后若未被 notify，自动重新竞争锁
• 注意：wait(long timeout) 不等于“超时后自动继续”，它只是避免永久挂起，仍需重新抢锁才能往下走

唤醒机制完全不同：sleep 靠时间，wait 靠 notify

sleep 是单向计时器，时间一到就醒；wait 是协作式等待，必须有另一个线程显式调用 notify 或 notifyAll 才能结束等待状态（除非设了超时）。

容易踩的坑：notify() 只随机唤醒一个等待线程，如果多个线程在等同一把锁，可能唤醒错人，导致部分线程永远等下去。生产环境更推荐 notifyAll()，再配合 while 循环检查条件（即“虚假唤醒”防护）。

• Thread.sleep(2000) → 2 秒后自动恢复运行（前提是没被 interrupt()）
• resource.wait() → 永远不会自己醒，必须有人调 resource.notify()
• 正确写法应是：

  synchronized (resource) {
      while (!conditionMet()) {
          resource.wait();
      }
      // 处理逻辑
  }

异常处理和中断响应都得接住 InterruptedException

两者都会响应线程中断（thread.interrupt()），并抛出 InterruptedException。但很多人只记得 catch，却忘了关键一点：**该异常发生时，线程的中断状态会被清除**。

这意味着如果你在 catch 块里啥也不做，上层逻辑就再也感知不到这次中断了——相当于“悄悄吞掉中断信号”。尤其在框架或线程池中，这可能导致任务无法被优雅终止。

• 必须在 catch 中恢复中断状态：Thread.currentThread().interrupt();
• 不要用空 catch 或只打日志就完事
• 不是所有场景都要立即退出，但中断意图要向上传递