Java 多线程同步问题的探究（四、协作，互斥下的协作——Java多线程协作（wait、notify、notifyAll））

核心提示： 运行这个程序吧，然后你会看到我们汉堡店的比赛进行的很好，Java 多线程同步问题的探究（四、协作，互斥下的协作——Java多线程协作（wait、notify、notifyAll））(8)，只是不 知道那些顾客是不是会被撑到，，这种协作实际上是一种互斥下的协作，下一讲当中，，读到这里

运行这个程序吧，然后你会看到我们汉堡店的比赛进行的很好，只是不

知道那些顾客是不是会被撑到。。。

读到这里，有的读者可能会想到前面介绍的重入锁ReentrantLock。

有的读者会问：如果我用ReentrantLock来代替上面这些例程当中的 synchronized块，是不是也可以呢？感兴趣的读者不妨一试。

但是在这里，我想提前给出结论，就是，

如果用ReentrantLock的lock()和unlock()方法代替上面的synchronized块，那么上面这些程序还是要抛出 java.lang.IllegalMonitorStateException异常的，不仅如此，你甚至还会看到线程死锁。原因就是当某个线程调用第三方对象的wait或者notify方法的时候，并没有进入第三方对象的监视器，于是抛出了异常信息。但此时，程序流程如果没有用finally来处理 unlock方法，那么你的线程已经被lock方法上锁，并且无法解锁。程序在java.util.concurrent框架的语义级别死锁了，你用 JConsole这种工具来检测JVM死锁，还检测不出来。

正确的做法就是，只使用ReentrantLock，而不使用wait或者notify方法。因为ReentrantLock已经对这种互斥和协作进行了概括。所以，根据你程序的需要，请单独采用重入锁或者synchronized一种同步机制，最好不要混用。

好了，我们现在明白：

1. 线程的等待或者唤醒，并不是让线程调用自己的wait或者notify方法，而是通过调用线程共享对象的wait或者notify方法来实现。

2. 线程要调用某个对象的wait或者notify方法，必须先取得该对象的监视器。

3. 线程的协作必须以线程的互斥为前提，这种协作实际上是一种互斥下的协作。

下一讲当中，我们来看看如何实实在在的解决线程之间抢占共享资源的问题。敬请期待！