Java中Thread.sleep和wait的核心差异在于锁的处理：Thread.sleep不释放已持有的锁，仅实现线程暂停；而Object.wait会释放当前对象锁，并进入等待队列，直到被notify、超时或中断，用于线程间协作。
在Java中，
Thread.sleep()
和
Object.wait()
虽然都能让当前线程暂停，但它们在并发控制机制上有着根本性的区别：
Thread.sleep()
仅仅是让线程“小憩”片刻，不涉及锁的释放；而
Object.wait()
则是线程主动“让出”它持有的锁，并进入等待状态，直到被其他线程唤醒。理解这一点，是编写健壮多线程代码的关键。
解决方案
要深入理解
Thread.sleep
与
Object.wait
的区别，我们得从它们各自的设计目的和对线程状态、锁机制的影响来分析。
Thread.sleep(long millis)
Thread.sleep()
是一个静态方法，它属于
Thread
类。当一个线程调用
Thread.sleep(long millis)
时，它会暂停当前线程的执行，进入“计时等待”（Timed Waiting）状态，持续指定的毫秒数。这个过程中，线程不会释放它当前持有的任何对象监视器锁（monitor lock）。这意味着如果一个线程在
synchronized
块中调用了
sleep()
，那么其他试图进入同一个
synchronized
块的线程仍然会被阻塞，直到
sleep()
时间结束，或者当前线程被中断。它的主要用途是引入一个简单的延时，比如在两次尝试之间等待，或者模拟一些耗时操作。
Object.wait()
(以及
wait(long millis)
、
wait(long millis, int nanos)
)
Object.wait()
是
Object
类的一个方法，这意味着任何对象都可以调用它。当一个线程在一个对象上调用
wait()
方法时，它会执行以下几个关键动作：
立即学习“Java免费学习笔记（深入）”；
释放对象监视器锁： 这是
wait()
与
sleep()
最本质的区别。调用
wait()
的线程会立即释放它在当前对象上持有的锁。进入等待状态： 线程会进入“等待”（Waiting）或“计时等待”（Timed Waiting）状态，并把自己放入该对象的等待队列中。等待被唤醒： 线程会一直等待，直到：另一个线程在该对象上调用了
notify()
或
notifyAll()
方法。如果调用的是
wait(long millis)
，等待时间超时。线程被中断（抛出
InterruptedException
）。出现所谓的“虚假唤醒”（Spurious Wakeups），尽管不常见，但JLS允许发生，所以总是需要在循环中检查条件。
wait()
方法必须在同步块（
synchronized
块或方法）中调用，并且同步的对象必须是
wait()
被调用的那个对象。如果不是这样，会抛出
IllegalMonitorStateException
。
wait()
的核心作用是实现线程间的协作，即一个线程等待某个条件满足，而另一个线程负责满足这个条件并通知等待的线程。
总结核心差异：| 特性 |
Thread.sleep()
|
Object.wait()
|| :———– | :——————————————— | :————————————————— || 锁的释放 | 不释放任何持有的锁 | 释放当前对象持有的锁 || 所属类 |
Thread
类 (静态方法) |
Object
类 (实例方法) || 使用场景 | 简单的时间延迟，暂停当前线程 | 线程间协作，等待特定条件满足后被唤醒 || 同步要求 | 无强制要求，可以在任何地方调用 | 必须在
synchronized
块/方法中调用，且同步对象与调用
wait()
的对象一致 || 唤醒方式 | 只能由时间到期或被中断唤醒 | 可以被
notify()
/
notifyAll()
唤醒，时间到期或被中断唤醒 |
public class SleepAndWaitDifference { private static final Object lock = new Object(); private static boolean conditionMet = false; public static void main(String[] args) throws InterruptedException { // 示例1: Thread.sleep 不释放锁 Thread sleepThread = new Thread(() -> { synchronized (lock) { System.out.println(Thread.currentThread().getName() + ": 获取到锁，准备sleep..."); try { Thread.sleep(2000); // 暂停2秒，但不释放锁 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println(Thread.currentThread().getName() + ": sleep结束，释放锁。"); } }, "SleepThread"); Thread blockingThread = new Thread(() -> { System.out.println(Thread.currentThread().getName() + ": 尝试获取锁..."); synchronized (lock) { // 会被SleepThread阻塞 System.out.println(Thread.currentThread().getName() + ": 成功获取到锁。"); } }, "BlockingThread"); sleepThread.start(); // 确保SleepThread先获取锁 Thread.sleep(100); blockingThread.start(); sleepThread.join(); blockingThread.join(); System.out.println("--- Sleep 示例结束 ---n"); // 示例2: Object.wait 释放锁 Thread waitingThread = new Thread(() -> { synchronized (lock) { System.out.println(Thread.currentThread().getName() + ": 获取到锁，准备wait..."); while (!conditionMet) { // 使用while循环防止虚假唤醒 try { lock.wait(); // 释放锁并等待 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } System.out.println(Thread.currentThread().getName() + ": 被唤醒，条件满足，继续执行，释放锁。"); } }, "WaitingThread"); Thread notifyingThread = new Thread(() -> { System.out.println(Thread.currentThread().getName() + ": 准备通知..."); try { Thread.sleep(1000); // 模拟一些工作 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } synchronized (lock) { // 必须获取到锁才能notify conditionMet = true; System.out.println(Thread.currentThread().getName() + ": 改变条件，并调用notifyAll()..."); lock.notifyAll(); // 唤醒所有等待的线程 } }, "NotifyingThread"); waitingThread.start(); Thread.sleep(100); // 确保waitingThread先进入wait状态 notifyingThread.start(); waitingThread.join(); notifyingThread.join(); System.out.println("--- Wait/Notify 示例结束 ---"); }}
运行上述代码，你会清晰地看到
BlockingThread
在
SleepThread
释放锁之前无法执行，而
NotifyingThread
可以在
WaitingThread
释放锁后获取锁并进行操作。
Java中Thread.sleep和wait方法在并发编程中的核心差异是什么？
最核心的差异在于它们对对象监视器锁（monitor lock）的处理方式。
Thread.sleep()
在暂停当前线程执行时，不会释放任何它已经持有的锁。这意味着，如果一个线程在同步块内部调用
sleep()
，那么它会一直持有这个锁，其他任何试图获取这个锁的线程都会被阻塞，直到
sleep()
结束或者当前线程被中断。这使得
sleep()
更适合用于简单的、不涉及资源共享竞争的延迟场景。
相比之下，
Object.wait()
的设计初衷就是为了解决线程间的协作问题，因此它在使当前线程进入等待状态的同时，会主动释放它持有的当前对象的锁。这个行为至关重要，因为它允许其他线程有机会获取到这个锁，进而修改共享资源的状态，并最终通过
notify()
或
notifyAll()
来唤醒等待的线程。这种机制是实现生产者-消费者模式、线程池等复杂并发结构的基础。
此外，
wait()
方法的唤醒机制也更为灵活。除了可以像
sleep()
那样因时间到期或被中断而唤醒外，它还能被其他线程通过
notify()
或
notifyAll()
方法显式唤醒，这使得它能够响应外部事件，实现条件等待。而
sleep()
则完全是被动的，只能等待时间流逝。
如何在实际场景中正确选择使用Thread.sleep还是Object.wait()？
选择
Thread.sleep
还是
Object.wait()
，完全取决于你的应用场景和需求：
选择
Thread.sleep()
的场景：当你需要一个简单、时间驱动的暂停，并且不希望释放任何锁，或者根本没有锁需要释放时，
Thread.sleep()
是合适的选择。
引入固定延迟： 例如，在UI动画中，你可能希望每隔一段时间更新画面；或者在重试机制中，等待一段时间后再次尝试连接。模拟耗时操作： 在测试或开发阶段，你可能需要模拟一个网络请求或数据库查询的延迟。降低CPU使用率： 在某些轮询（polling）场景中，为了避免CPU空转，可以在每次轮询之间加入短暂的
sleep()
，但通常有更好的并发工具来替代这种模式。无需线程间协作： 你的线程只是自己暂停一下，不依赖其他线程改变状态来继续执行。
选择
Object.wait()
(配合
notify()
/
notifyAll()
) 的场景：当你需要实现线程间的协作，让一个线程等待某个特定条件满足，并且在等待期间需要释放锁，以便其他线程能够改变这个条件时，
Object.wait()
是不可或缺的。
生产者-消费者模式： 生产者线程生产数据放入共享队列，如果队列满则
wait()
；消费者线程从队列取数据，如果队列空则
wait()
。当有数据或空间时，另一方
notify()
唤醒。等待资源可用： 一个线程需要某个资源，如果资源不可用，它就
wait()
，直到另一个线程释放或创建了资源并
notify()
它。实现自定义同步器： 像
BlockingQueue
、
CountDownLatch
等并发工具的底层实现，都离不开
wait()
和
notify()
机制。条件等待： 线程需要等待某个布尔标志变为
true
，或者某个计数器达到特定值。
关键的决策点在于： 你暂停线程的目的是什么？是为了单纯的时间延迟，还是为了等待某个条件的改变？如果涉及到共享资源和线程间的条件依赖，并且需要释放锁以便其他线程能够修改这些条件，那么
wait()
/
notify()
是唯一的选择。否则，如果只是简单的暂停，
sleep()
就足够了。
Object.wait()方法使用时有哪些常见的陷阱和最佳实践？
Object.wait()
虽然强大，但使用起来却充满了“陷阱”，稍有不慎就可能导致死锁、活锁或程序行为异常。
稿定AI社区
在线AI创意灵感社区
60 查看详情 
常见陷阱：
不在
synchronized
块中调用
wait()
： 这是最常见的错误。
wait()
、
notify()
和
notifyAll()
必须在同步块内部调用，并且同步的对象必须是调用这些方法的对象。否则，会立即抛出
IllegalMonitorStateException
。
// 错误示例// lock.wait(); // 如果不在synchronized(lock)块中，会抛出IllegalMonitorStateException
虚假唤醒（Spurious Wakeups）： 线程可能在没有收到
notify()
或
notifyAll()
的情况下被唤醒。这是Java虚拟机规范允许的行为。如果你的代码仅仅使用
if (condition)
来检查条件，那么在虚假唤醒后，线程可能在条件未满足的情况下继续执行，导致逻辑错误。
// 错误示例 (可能导致虚假唤醒后条件不满足却继续执行)// if (!conditionMet) {// lock.wait();// }
notify()
与
notifyAll()
的误用：
notify()
只会唤醒一个等待线程（具体是哪一个由JVM决定，通常是等待时间最长的）。如果多个线程在等待不同的条件，或者你需要所有等待的线程都检查条件，那么使用
notify()
可能会导致某些线程永远得不到唤醒（“信号丢失”）。在生产者-消费者场景中，如果生产者
notify()
了一个消费者，但队列仍然为空，那么被唤醒的消费者可能再次
wait()
，而此时可能还有其他消费者在等待，它们就永远不会被唤醒。
死锁： 如果
notify()
/
notifyAll()
的线程没有正确地改变条件，或者
wait()
的线程在唤醒后没有再次检查条件，就可能导致线程永久等待。
信号丢失： 如果
notify()
在
wait()
之前执行，那么
notify()
的信号就会丢失，后续调用
wait()
的线程将永远等待。
最佳实践：
始终在
while
循环中检查等待条件： 这是对抗虚假唤醒和确保条件真正满足的关键。当线程被唤醒时，它应该重新评估条件，如果条件仍然不满足，则再次调用
wait()
。
synchronized (lock) { while (!conditionMet) { // 必须使用while循环 try { lock.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 处理中断逻辑，例如重新设置条件，或者退出循环 return; } } // 条件满足，继续执行}
总是使用
notifyAll()
而非
notify()
： 除非你有一个非常明确且经过验证的理由只唤醒一个线程。
notifyAll()
可以确保所有等待的线程都有机会检查条件，避免“信号丢失”或“活锁”的情况。虽然
notifyAll()
可能唤醒一些不必要的线程，导致它们再次
wait()
，但这种开销通常比死锁或逻辑错误要小得多。
确保
notify()
/
notifyAll()
在条件改变后且持有锁时调用： 改变共享变量的状态和调用
notify()
必须在同一个
synchronized
块中完成，这样可以保证原子性，避免竞争条件和信号丢失。
synchronized (lock) { conditionMet = true; // 改变条件 lock.notifyAll(); // 唤醒等待线程}
优先使用
java.util.concurrent
包中的高级并发工具： Java并发包提供了许多更高级、更健壮、更易于使用的工具，如
BlockingQueue
、
CountDownLatch
、
Semaphore
、
CyclicBarrier
、
ReentrantLock
配合
Condition
等。它们在底层封装了
wait()
/
notify()
的复杂性，并处理了许多常见的陷阱，大大降低了并发编程的难度。
例如，对于生产者-消费者模式，直接使用
ArrayBlockingQueue
或
LinkedBlockingQueue
远比手动编写
wait()
/
notify()
安全和高效。如果需要更细粒度的条件等待，
ReentrantLock
的
newCondition()
方法返回的
Condition
对象提供了
await()
、
signal()
和
signalAll()
，它们的功能与
Object.wait()
、
notify()
和
notifyAll()
类似，但提供了更强大的灵活性和控制力，并且可以有多个条件变量。
遵循这些最佳实践，可以帮助你编写出更可靠、更易于维护的并发代码。在大多数情况下，如果不是在编写底层的并发库，你都应该考虑优先使用
java.util.concurrent
包提供的工具。
以上就是Java中Thread.sleep与wait区别的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/327152.html
微信扫一扫 
支付宝扫一扫 
