引言
在Java的多线程编程中，wait(), notify()和notifyAll()是用于线程间通信的重要方法。面试官经常会问到这些方法为何被定义在Object类中，而不是Thread类中。让我们通过一次面试对话来深入探讨这个问题。
面试过程
面试官：你好，小李。你能解释一下为什么wait(), notify()和notifyAll()这些方法被定义在Object类而不是Thread类中吗？
小李：当然，这个问题涉及到Java中对象锁（Monitor）的概念。wait(), notify()和notifyAll()实际上是用于控制线程对共享对象的访问，而不是直接与线程本身相关。
面试官：我明白这些方法与共享资源有关，但是为什么它们不是定义在Thread类中呢？
小李：如果这些方法定义在Thread类中，那么它们只能用于Thread对象，而不能用于其他对象。但是，多线程同步的需求并不仅仅局限于Thread对象，任何对象都可能成为多个线程争夺的资源。将这些方法定义在Object类中，意味着任何对象都可以用作同步锁，这大大扩展了它们的使用场景。
面试官：这个解释很合理。那么，你能从源码层面解释一下这些方法是如何工作的吗？
小李：当然可以。在Java中，每个对象都有一个与之关联的Monitor，当线程尝试获取对象的Monitor时，会被放入Monitor的等待队列中。如果获取成功，线程便拥有了该对象的锁。wait()方法会使当前线程释放对象的Monitor并进入等待状态，直到其他线程调用notify()或notifyAll()唤醒它。
面试官：那么，notify()和notifyAll()有什么区别呢？
小李：notify()只会唤醒一个等待该对象锁的线程，而notifyAll()会唤醒所有等待该对象锁的线程。如果只使用notify()，可能会造成某些线程饿死的情况，因为只有一个线程被唤醒，其他线程可能会无限期地等待。使用notifyAll()可以确保所有线程都有机会被唤醒，从而避免饿死问题。
面试官：我明白了。那么，这些方法的使用有没有什么限制或者需要注意的事项？
小李：使用这些方法时，必须在同步方法或同步代码块中调用，否则会抛出IllegalMonitorStateException。此外，调用wait()方法时，当前线程必须拥有对象的Monitor，否则会抛出IllegalThreadStateException。同时，wait()方法会释放对象的Monitor，允许其他线程进入同步代码块。
面试官：非常好，小李。你的解释很深入，也很清晰。我还想问一个更深入的问题，你能从JVM层面解释一下wait(), notify()和notifyAll()的实现原理吗？
小李：当然可以。在JVM层面，wait(), notify()和notifyAll()是通过Monitor对象来实现的。Monitor依赖于底层的操作系统的Mutex锁，当一个线程获取Monitor时，它就拥有了对象的锁。wait()方法会释放Monitor并使线程进入等待状态，notify()和notifyAll()则会唤醒等待队列中的线程，使它们重新尝试获取Monitor。
面试官：你能给我一个具体的代码示例吗？
小李：当然可以。下面是一个简单的生产者-消费者问题的示例，展示了如何使用wait()和notify()方法来同步线程对共享资源的访问。
public class SharedObject {
private int number;
public synchronized void increment() {
while (number != 0) {
try {
wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
number++;
notifyAll();
}
public synchronized int getNumber() {
while (number == 0) {
try {
wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
int value = number;
number = 0;
notifyAll();
return value;
}
}
在这个例子中，SharedObject类有一个number成员，increment方法在number不为0时等待，getNumber方法在number为0时等待。当number的值改变时，相应的方法会通知其他线程。
面试官：这个例子很好。那么，为什么notifyAll()通常比notify()更安全呢？
小李：notifyAll()会唤醒所有等待的线程，这样可以确保所有线程都有机会被唤醒，从而避免饿死问题。而notify()只会唤醒一个线程，如果选择不当，可能会导致某些线程长时间得不到唤醒。
面试官：非常好，小李。你的解释很深入，也很清晰。我认为你已经很好地理解了Java中这些同步方法的设计理念和作用。现在，我想进一步探讨一下，这些方法在JVM层面是如何实现的，你能从源码级别给我一些更深入的解释吗？
小李：当然可以。在JVM层面，wait(), notify()和notifyAll()的实现涉及到了一些本地方法（native methods），这些方法直接与操作系统的Mutex锁进行交互。例如，wait()方法会调用JVM_MonitorWait，而notify()和notifyAll()会调用JVM_MonitorNotify和JVM_MonitorNotifyAll。这些本地方法会操作Monitor对象，这个对象在HotSpot虚拟机中是由ObjectMonitor类实现的。
面试官：你能详细解释一下ObjectMonitor吗？
小李：ObjectMonitor是HotSpot虚拟机中实现Monitor锁的核心组件。它主要包含以下几个部分：
- ObjectWord：指向被锁定对象的指针。
- Owner：指向当前持有Monitor的线程对象。
- WaitSet和EntryList：两个队列，分别用于存储等待锁的线程和等待进入Monitor的线程。
当一个线程调用wait()方法时，它会释放Monitor并进入WaitSet队列中。而notify()和notifyAll()会将WaitSet中的线程移动到EntryList队列中，然后线程会重新尝试获取Monitor锁。
面试官：那么，这个过程中是否存在性能优化的空间呢？
小李：是的，JVM对Monitor锁进行了多种优化，包括轻量级锁（Lightweight Locking）和偏向锁（Biased Locking）。轻量级锁使用了CAS（Compare-And-Swap）操作来尝试获取锁，这避免了操作系统层面的Mutex锁的开销。而偏向锁则是基于对象通常被单个线程多次锁定的假设，它会偏向于第一个获取它的线程，从而减少CAS操作的次数。
面试官：这些优化措施确实很有意义。那么，你有没有遇到过死锁或者性能瓶颈的问题？在实际开发中，你是如何避免这些问题的？
小李：在实际开发中，确实会遇到死锁或者性能瓶颈的问题。为了避免这些问题，我会采取以下措施：
- 减少锁的粒度：尽量缩小同步代码块的范围，只对必要的部分进行同步。
- 使用读写锁：在读操作远多于写操作的场景中，使用
ReadWriteLock可以提高性能。 - 避免在循环中使用同步块：这样可以减少锁的争用，避免性能瓶颈。
- 使用并发集合：
java.util.concurrent包提供了多种线程安全的集合类，它们通常比手动同步的集合类有更好的性能。 - 使用
CompletableFuture：在Java 8中引入的CompletableFuture提供了一种非阻塞的异步编程方式，可以提高程序的响应性和吞吐量。
面试官：非常好，小李。你的解释不仅深入，而且涵盖了实际开发中的优化策略。我认为你已经很好地掌握了Java多线程同步机制的设计理念和实际应用。
结论
通过这次面试，小李展示了他对Java多线程同步机制的深刻理解。他解释了为什么wait(), notify()和notifyAll()方法被定义在Object类中，而不是Thread类中，并且通过一个实际的代码示例来说明了它们的用法。这个问题的讨论不仅涉及到了Java的内存模型，还涉及到了线程间协作的基本原则。此外，小李还深入探讨了这些方法在JVM层面的实现原理，并提供了一些实际开发中的性能优化策略。
