经过假设了解为何 wait/notify 定义在 Object 类中

这是一个老生常谈的面试题了，wait 和 notify 配合监视器提供了多个同步线程之间通讯机制，答案自己也很简单，因为通讯自己解决的就是锁的归属问题（发现当前应该把锁给别人时调用 wait， 通知别人能够来用锁了调用 notify），从功能上讲，放在 Object 类（锁对象）中本就是理所固然的。

但咱们能够换个角度去思考，不妨使用假设法，假设 wait 和 notify 是放在 Thread 类中，看看使用的状况会是怎么样的。

因为线程之间并不知道其余对象获取锁的状况，须要额外的开销去记录和遍历其余线程的状况，而且一个线程其实是能够拥有多个锁的。所以，要实现线程通讯机制，有两个必不可少的参数，线程和锁对象。

synchronized(lock) {
    Thread.currentThread().wait(lock);
}
复制代码

若是是这么使用的话其实没有什么问题，从功能上来讲其实和 lock.wait() 没有什么区别。可是，只要有存在的可能，就必定会发生。有些人可能恰好因为契合某些业务来实现某些功能会写出如下代码：

List<Thread> threadList = ...

synchronized(lock) {
    threadList.get(i).wait(lock);
}
复制代码

在当前线程的代码容许其余的线程在所需的锁上等待，这种“入侵”式的代码给设计和维护带来了许多的困难，本来并发程序就很差调式，这样一来就更加的混乱，而且产生没法预计和复现的错误。毕竟可能让使用者产生错误用法的设计就不是一个好的设计。