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

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

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

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

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

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

立刻松手，别人就能进来了。

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

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

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

正确写法应是：

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

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

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

真正难的不是记住“wait 释放锁、sleep 不释放”，而是写对 while + wait 循环、选对 notify 还是 notifyAll、以及中断处理不丢信号——这些细节才决定多线程代码到底稳不稳定。

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