为什么java中wait/notify/notifyAll方法不同步？

Question

在Java中，每当我们需要调用wait/notify/notifyAll时，我们都需要访问对象监视器（通过synchronized方法或通过synchronized块）。所以我的问题是为什么java不采用同步等待/通知方法来消除从同步块或方法调用这些方法的限制。

如果这些被声明为同步，它将自动获取监视器访问权限。

Answer 1

对于notify和notifyAll，您的想法的问题在于，当您通知时，您通常还会在同一个同步块中执行其他操作。因此，使通知方法同步不会给你带来任何好处，你仍然需要该块。同样，wait 必须位于同步块或方法中才能有用，例如位于自旋锁内，无论如何测试都必须同步。因此，锁定的粒度对于您的建议来说是完全错误的。

下面是一个例子，这是 Java 中最简单的队列实现：

public class MyQueue<T> {

    private List<T> list = new ArrayList<T>();

    public T take() throws InterruptedException {
        synchronized(list) {
            while (list.size() == 0) {
                list.wait();
            }
            return list.remove(0);
        }
    }

    public void put(T object) {
        synchronized(list) {
            list.add(object);
            list.notify();
        }
    }
}

因此，您可以使用生产者线程将内容添加到队列中，使用消费者线程将内容取出。当线程要从队列中获取某些内容时，它需要在同步块内检查列表中是否有某些内容，一旦收到通知，它需要重新获取锁并确保列表中仍然有某些内容（因为某些其他消费者线程可能会介入并抓住它）。还有“虚假唤醒”现象：你不能依赖被唤醒作为发生了某些事情的充分证据，你需要检查你正在等待的任何条件因为这实际上是真的，这需要在同步块内完成。

在这两种情况下，都需要在持有锁的情况下进行围绕等待的检查，以便当代码根据这些检查采取操作时，它知道这些结果当前是有效的。

（如果您的用例没有如上所述需要更改的状态，则同步可能是不适合该工作的工具。使用其他一些方法，例如 CountdownLatch，可能会为您提供更简单的解决方案。）

Answer 2

好问题。 JDK7 对象实现 中的注释阐明了一些情况我认为（强调我的）：

此方法导致当前线程（称之为T）放置
本身处于该对象的等待集中，然后放弃任何
以及此对象上的所有同步声明。

...

然后线程T将从等待集中删除
通常的方式与其他线程同步的权利
目的;一旦它获得了对物体的控制，它的所有
对象上的同步声明恢复到原状
ante - 即 wait 时的情况
方法被调用。 线程 T 然后从
调用wait方法。因此，从
wait方法，对象与线程的同步状态
T 与调用 wait 方法时完全相同
调用。

所以我认为首先要注意的一点是 wait() 在调用者完成等待之前不会返回（显然）。这意味着如果 wait() 本身是同步的，那么调用者将继续持有该对象的锁，并且其他人都无法 wait() 或 通知（）。

现在显然 wait() 正在幕后做一些棘手的事情，以强制调用者无论如何都失去对象锁的所有权，但也许这个技巧不起作用（或者会更难实现） make work) 如果 wait() 本身已同步。

第二点是，如果多个线程正在等待一个对象，当使用 notify() 来唤醒其中一个线程时，将使用标准争用方法来仅允许一个线程在该对象上同步，并且 wait() 应该将调用者的同步声明恢复到调用 wait() 之前的确切状态。在我看来，要求调用者在调用 wait() 之前持有锁可能会简化这一点，因为它不需要检查调用者是否应该在调用之后继续持有锁。 wait() 返回。合约规定调用者必须继续持有锁，因此简化了一些实现。

或者可能只是为了避免出现“如果 wait() 和 notify() 都是同步的，并且 wait()<”的逻辑悖论。 /code> 在调用 notify() 之前不会返回，如何才能成功使用？”。

无论如何，这些是我的想法。

Answer 3

我的猜测是，需要 synchronized 块的原因是使用 wait() 或 notify() 作为无论如何，同步块几乎总是一个错误。

Findbugs 甚至对此有一个警告，它称之为“裸通知"。

Answer 4

在我读过和写过的所有无错误代码中，它们都在更大的同步块中使用了 wait/notify ，涉及其他条件的读/写

synchronized(lock)
    update condition
    lock.notify()

synchronized(lock)
    while( condition not met)
        lock.wait()

If wait/notify > 本身同步，不会对所有正确的代码造成任何损害（可能会造成很小的性能损失）；它对所有正确的代码也没有任何好处。

然而，它会允许并鼓励更多的错误代码。

Answer 5

对多线程更有经验的人应该可以随意介入，但我相信这会消除同步块的多功能性。使用它们的目的是在充当受监视资源/信号量的特定对象上进行同步。然后使用 wait/notify 方法来控制同步块内的执行流程。

请注意，同步方法是在方法（或静态方法的类）持续时间内同步 this 的简写。同步等待/通知方法本身将消除它们用作线程之间的停止/执行信号的意义。

Answer 6

同步的等待通知模型要求您在继续执行任何工作之前首先获取对象上的监视器。它与同步块使用的互斥模型不同。

等待通知或相互合作模型通常用于生产者-消费者场景，其中一个线程生成由另一个线程消费的事件。编写良好的实现将努力避免消费者饥饿或生产者因太多事件而超出消费者的情况。为了避免这种情况，您可以使用等待通知协议，其中

• 消费者等待生产者生成事件。
• 生产者生成事件并通知消费者，然后通常会进入休眠状态，直到消费者通知。
• 当消费者收到事件通知时，它会醒来，处理该事件，并通知生产者它已完成对事件的处理。

在这种情况下，您可能有许多生产者和消费者。通过互斥模型获取监视器，在 wait、notify 或 notifyAll 上必然会破坏此模型，因为生产者和消费者都这样做不显式执行等待。底层线程将出现在监视器的等待集（由等待通知模型使用）或条目集（由互斥模型使用）中。调用 notify 或 notifyAll 向线程发出信号，将其从等待集移动到监视器的条目集（其中多个线程之间可能存在监视器争用） ，而不仅仅是最近通知的）。

现在，当您想要使用互斥模型自动获取 wait、notify 和 notifyAll 上的监视器时，通常表明您不需要使用等待通知模型。这是推断 - 通常，只有在一个线程中完成一些工作（即状态发生变化）后，您才会向其他线程发出信号。如果您自动获取监视器并调用 notify 或 notifyAll，您只是将线程从等待集移动到入口集，程序中没有任何中间状态，这意味着认为过渡是不必要的。很明显，JVM 的作者意识到了这一点，并且没有将这些方法声明为同步的。

您可以在 Bill Venner 的书中阅读有关监视器的等待集和入口集的更多信息 - Inside the Java虚拟机。

Answer 7

我认为没有 synchronized 的 wait 在某些情况下可以很好地工作。但它不能用于没有竞争条件的复杂场景，可能会发生“虚假唤醒”。

代码适用于队列。

// producer
give(element){
  list.add(element)
  lock.notify()
}

// consumer
take(){
  obj = null;
  while(obj == null)
    lock.wait()
    obj = list.remove(0) // ignore error indexoutofrange
  return obj
}

此代码没有解释共享数据的状态，它将忽略最后一个元素，并且可能无法在多线程条件下工作。如果没有竞争条件，1、2 中的列表可能具有完全不同的状态。

// consumer
take(){
  while(list.isEmpty()) // 1
    lock.wait()
  return list.remove(0) // 2
}

现在，让它变得更加复杂和明显。

执行指令

• give(element) lock.notify()->take() lock.wait()复活->take() list.remove(0)->rollback(element)
• give(element) lock.notify()->take() lock.wait()复活->rollback(element)->take() list.remove(0)

“虚假唤醒”发生，也会使代码不可预测。

// producer
give(element){
  list.add(element)
  lock.notify()
}
rollback(element){
  list.remove(element)
}

// business code 
produce(element){
   try{
     give(element)
   }catch(Exception e){
     rollback(element) // or happen in another thread
   }
}

// consumer
take(){
  obj = null;
  while(obj == null)
    lock.wait()
    obj = list.remove(0) // ignore error indexoutofrange
  return obj
}

Chris Smith 的参考
insidevm 参考