多个线程可以在同一个监听器对象上调用wait()，它们会阻塞等待notify()或notifyAll()。调用notify()将会仅唤醒一个等待的线程。调用notifyAll()将会唤醒所有等待的线程。

　　一个线程只能在持有同步锁的情况下调用wait()，notify()，notifyAll()，否则会抛出IllegalMonitorStateException 异常。

• 丢失的信号

　　我们上面提到了，线程间的通信--信号。 那么什么是丢失的信号呢？

　　The methods notify() and notifyAll() do not save the method calls to them in case no threads are waiting when they are called. The notify signal is then just lost. Therefore, if a thread calls notify() before the thread to signal has called wait(), the signal will be missed by the waiting thread. This may or may not be a problem, but in some cases this may result in the waiting thread waiting forever, never waking up, because the signal to wake up was missed.

　　To avoid losing signals they should be stored inside the signal class. In the MyWaitNotify example the notify signal should be stored in a member variable inside the MyWaitNotify instance. Here is a modified version of MyWaitNotify that does this:

　　wait()，notify(), notifyAll()等方法不会保存方法的调用，以防在调用时没有等待的线程。这样通知的信号就会被丢弃。因此，如果一个线程调用notify()的时机在线程调用wait()之前，等待线程的信号将会被丢失，这也许是一个问题也许不是问题，但在某些情况下，这些等待的线程也许永远无法被唤醒了。

　　为了应对这种情况，这些被丢失的信号应该被放在实例中存储。实例：MyWaitNotify实例代码，通知信号应该被存储在当前的实例中。以下是MyWaitNotify的一个修改版本的模板：

public class MyWaitNotify2{

  MonitorObject myMonitorObject = new MonitorObject();
  boolean wasSignalled = false;

  public void doWait(){
    synchronized(myMonitorObject){
      if(!wasSignalled){
        try{
          myMonitorObject.wait();
         } catch(InterruptedException e){...}
      }
      //clear signal and continue running.
      wasSignalled = false;
    }
  }

  public void doNotify(){
    synchronized(myMonitorObject){
      wasSignalled = true;
      myMonitorObject.notify();
    }
  }
}

　　Notice how the doNotify() method now sets the wasSignalled variable to true before calling notify(). Also, notice how the doWait() method now checks the wasSignalled variable before calling wait(). In fact it only calls wait() if no signal was received in between the previous doWait() call and this.

　　通知doNotify()是在调用notify()之前将wasSignaled设置为true，另外，通知信号如何在调用wait()前去检查信号的。事实上，只有在前一个调用doWait()和当前调用之间没有接收到信号的情况下，才会调用wait()。

• 虚假唤醒

　　For inexplicable reasons it is possible for threads to wake up even if notify() and notifyAll() has not been called. This is known as spurious wakeups. Wakeups without any reason.

　　If a spurious wakeup occurs in the MyWaitNofity2 class's doWait() method the waiting thread may continue processing without having received a proper signal to do so! This could cause serious problems in your application.

　　To guard against spurious wakeups the signal member variable is checked inside a while loop instead of inside an if-statement. Such a while loop is also called a spin lock. The thread awakened spins around until the condition in the spin lock (while loop) becomes false. Here is a modified version of MyWaitNotify2 that shows this:

　　在一些无法解释的情况下，线程在没有调用notify()或notifyAll()的情况下，会自动的唤醒。这种情况就叫做虚假唤醒。虚假唤醒是毫无理由的醒来。

　　如果MyWaitNofity2的doWait()触发了虚假唤醒，那么等待线程可能在没有收到信号的情况下处理，这将会让你的应用程序发生错误。

　　为了防止虚假唤醒，成员变量信号应该在while中而不是在if else中检查。这样的做法while loop也成为自旋锁--spin lock。当前线程会一直自旋直到条件变为false。下面是MyWaitNotify2 的修改版本：

public class MyWaitNotify3{

  MonitorObject myMonitorObject = new MonitorObject();
  boolean wasSignalled = false;

  public void doWait(){
    synchronized(myMonitorObject){
      while(!wasSignalled){
        try{
          myMonitorObject.wait();
         } catch(InterruptedException e){...}
      }
      //clear signal and continue running.
      wasSignalled = false;
    }
  }

  public void doNotify(){
    synchronized(myMonitorObject){
      wasSignalled = true;
      myMonitorObject.notify();
    }
  }
}

　　Notice how the wait() call is now nested inside a while loop instead of an if-statement. If the waiting thread wakes up without having received a signal, the wasSignalled member will still be false, and the while loop will execute once more, causing the awakened thread to go back to waiting.

　　现在调用wait()是嵌套在while循环中的，而不是if语句中。如果等待线程无条件的虚假唤醒，当前的信号量仍旧为false，唤醒的线程将会再通过自旋返回wait()。

• 多个线程等待相同的信号

　　The while loop is also a nice solution if you have multiple threads waiting, which are all awakened using notifyAll(), but only one of them should be allowed to continue. Only one thread at a time will be able to obtain the lock on the monitor object, meaning only one thread can exit the wait() call and clear the wasSignalled flag. Once this thread then exits the synchronized block in the doWait() method, the other threads can exit the wait() call and check the wasSignalled member variable inside the while loop. However, this flag was cleared by the first thread waking up, so the rest of the awakened threads go back to waiting, until the next signal arrives.　　

　　这种while-loop自旋的操作，在面对多个线程等待时，也同样适用。当任意一个线程调用notifyAll()后，只有一个线程会允许继续操作。只有一个线程可以获取到监视器的锁，也就只有当前获取锁的线程可以退出wait()并清除wasSignalled信号。当这个线程指定doWait()退出同步块后，其他线程才允许退出wait()并且自旋检查wasSignalled。当然，这个信号被这个线程唤醒清除，其他被唤醒的线程则返回继续等待，直到下一个信号的来临。

• 不要在常量String或全局对象调用wait()

　　An earlier version of this text had an edition of the MyWaitNotify example class which used a constant string ( "" ) as monitor object. Here is how that example looked:

　　一个古老版本的例子MyWaitNotify使用了常量字符串"" 作为一个监视器对象。实例代码如下：

public class MyWaitNotify{

  String myMonitorObject = "";
  boolean wasSignalled = false;

  public void doWait(){
    synchronized(myMonitorObject){
      while(!wasSignalled){
        try{
          myMonitorObject.wait();
         } catch(InterruptedException e){...}
      }
      //clear signal and continue running.
      wasSignalled = false;
    }
  }

  public void doNotify(){
    synchronized(myMonitorObject){
      wasSignalled = true;
      myMonitorObject.notify();
    }
  }
}

　　The problem with calling wait() and notify() on the empty string, or any other constant string is, that the JVM/Compiler internally translates constant strings into the same object. That means, that even if you have two different MyWaitNotify instances, they both reference the same empty string instance. This also means that threads calling doWait() on the first MyWaitNotify instance risk being awakened by doNotify() calls on the second MyWaitNotify instance.

　　对一个空的字符串或其他常量字符串作为监视器对象的问题在于：对于JVM来说，在编译时会将这种常量字符串作为一个相同的实例。（这里参考 JVM的内存模型 以及JVM的常量池）这意味着，即使有两个不相同的MyWaitNotify 实例，它们用的都是同一个字符串实例。这也意味着在第一个MyWaitNotify 上调用的doWait()方法的实例，有可能会被第二个MyWaitNotify 唤醒的风险。

　　情况如下图所示：

　　Remember, that even if the 4 threads call wait() and notify() on the same shared string instance, the signals from the doWait() and doNotify() calls are stored individually in the two MyWaitNotify instances. A doNotify() call on the MyWaitNotify 1 may wake threads waiting in MyWaitNotify 2, but the signal will only be stored in MyWaitNotify 1.

　　At first this may not seem like a big problem. After all, if doNotify() is called on the second MyWaitNotify instance all that can really happen is that Thread A and B are awakened by mistake. This awakened thread (A or B) will check its signal in the while loop, and go back to waiting because doNotify() was not called on the first MyWaitNotify instance, in which they are waiting. This situation is equal to a provoked spurious wakeup. Thread A or B awakens without having been signaled. But the code can handle this, so the threads go back to waiting.

　　The problem is, that since the doNotify() call only calls notify() and not notifyAll(), only one thread is awakened even if 4 threads are waiting on the same string instance (the empty string). So, if one of the threads A or B is awakened when really the signal was for C or D, the awakened thread (A or B) will check its signal, see that no signal was received, and go back to waiting. Neither C or D wakes up to check the signal they had actually received, so the signal is missed. This situation is equal to the missed signals problem described earlier. C and D were sent a signal but fail to respond to it.

　　If the doNotify() method had called notifyAll() instead of notify(), all waiting threads had been awakened and checked for signals in turn. Thread A and B would have gone back to waiting, but one of either C or D would have noticed the signal and left the doWait() method call. The other of C and D would go back to waiting, because the thread discovering the signal clears it on the way out of doWait().

　　You may be tempted then to always call notifyAll() instead notify(), but this is a bad idea performance wise. There is no reason to wake up all threads waiting when only one of them can respond to the signal.

　　So: Don't use global objects, string constants etc. for wait() / notify() mechanisms. Use an object that is unique to the construct using it. For instance, each MyWaitNotify3 (example from earlier sections) instance has its own MonitorObject instance rather than using the empty string for wait() / notify() calls.

　　请记住，即使四个线程使用同一个监视器对象调用wait()或者notify()，doWait()和doNotify()调用依旧会存储在不同的两个MyWaitNotify 实例上。A在MyWaitNotify1上调用doNotify()可能会唤醒MyWaitNotify2，但是信号的存储会在MyWaitNotify1上进行存储。

　　起初，这并不是一个大问题。当然，如果doNotify()会调用MyWaitNotify2实例发生线程A和线程B被错误的唤醒，那唤醒的线程A和B就会在while-loop中检查并再次wait，因为doNotify()可能作用于MyWaitNotify1实例上，最后它们都会去wait()，这种情况就相当于线程A，B被虚假唤醒，但是代码可以解决这种问题，所以线程又会回到等待状态。

　　这里的问题时：这里的doNotify()调用时，只会唤醒其中的一个线程（notify），并非唤醒多个线程，在这种情况下四个线程在常量字符串监听器中只会有一个线程被唤醒，所以，如果唤醒的线程是A或者B时，而信号作用于C或者D，那么A或者B醒来就会检查信号，查看没有接收到信号，那么又在自旋中等待。而C和D没有醒来查看它们的信号，那这个信号就会被丢弃。这种情况类似于信号丢失的场景。

　　如果doNotify()方法中调用的是notifyAll()，所有等待的线程都会被唤醒，然后检查信号。线程A和线程B将会在自旋中接着等待，但是C或者D其中一个会获取到锁并跳出doWait()，另一个将会再次回到等待状态，因为线程在跳出doWait()时会清除信号。

　　你也许会更倾向于notifyAll()而不是notify()，但这是一个不好的想法。当我们只需要一个线程响应信号时，不应该让所有的等待线程都被唤醒。

　　因此，不要使用全局对象、字符串常量使用wait()或者notify()，使用一个包含唯一构造的对象，例如MyWaitNotify3 的实例就包含自己的MonitorObject 实例，而不是使用上述错误的对象。

　　以上说明，选自雅各布·詹科夫-Jakob Jenkov的文章