本文为后续介绍AbstractQueuedSynchronizer.ConditionObject做一下铺垫。
Lock&Condition
Lock用于控制多线程对同一状态的顺序访问，保证该状态的连续性。
Condition用于控制多线程之间的、基于该状态的条件等待。
PS：这里的“同一状态”指的就是“需要争用的共享资源”。
举例说明（出自java Condition的注释）
这是一个简单的生产者消费者模型，生产者往buffer里put，消费者从buffer里take。
- 同一状态的顺序访问
有三个状态需要顺序访问：buffer的大小count，生产者用于put的游标putptr，消费者用于take的游标takeptr。 - 基于该状态的条件等待
当count = 0时，消费者的take需要等待；当count = buffer.size（buffer满了），生产者需要等待。
If a take is attempted on an empty buffer, then the thread will block until an item becomes available; if a put is attempted on a full buffer, then the thread will block until a space becomes available.
代码如下：
class BoundedBuffer {
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
final Object[] items = new Object[100];
int putptr, takeptr, count;
public void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)
notFull.await();
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
notEmpty.signal();
} finally {
lock.unlock();
}
}
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)
notEmpty.await();
Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count;
notFull.signal();
return x;
} finally {
lock.unlock();
}
}
}
这里，lock用于保证count, takeptr, putptr这三个状态的顺序访问，notFull和notEmpty用来控制基于count的条件等待。
lock的作用很好理解。大家都要修改同一个count，需要一个一个的来，而在根据count进行条件判断时，自然也是要先拿到这个lock，才能保证这个count的准确性。所以，不论是修改count，还是基于count进行判断，均是在lock之后执行。
不过，既然lock已经保证了一次只有一个线程能够访问count，那为何不能完全基于lock来实现一个生产者和消费者模型呢，要Condition作甚？我想了想，写了一个完全基于lock的put()。
public void put(Object x) throws InterruptedException {
while (true) {
lock.lock();
try {
if (count < items.length) {
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
break;
}
} finally {
lock.unlock();
}
}
}
这个put是基于循环来做的，获取到锁后，如果条件不满足，就释放锁，然后再继续获取锁。我觉得，这个版本在逻辑上应该是没问题的，是能够保证生产者消费者模型的正确执行的。不过，问题在于，不停的获取锁、释放锁，效率太低了，甚至可能出现某个生产者线程总是能够不停的成功获取锁，直接阻塞住其他的生产者或消费者，导致整个模型在一段时间内陷入停滞状态。
自然的解决方法就是，条件不满足时，挂起线程，在条件满足时，再唤醒。
挂起再唤醒，Lock干的也是类似的事情。不过，在生产者消费者模型中，当条件不满足时，应当立即挂起线程。而lock()并不是一个直接挂起线程的方法，获取锁失败时，才会挂起线程。
总之，多线程在对同一状态进行修改时，需要用Lock保证其一致性，而在线程需要基于该状态进行条件等待时，为了保证高效性，得有一个方法来控制线程在该条件上的挂起和唤醒。于是，Condition就应运而生了。因为Condition涉及到的状态，应是某个需要被Lock的状态，所以至少在有Lock的场景下，才会有Condition，这也是为什么Lock和Condition总是捉对出现。
Lock和Condition的实现简介
Lock和Condition的实现都是基于队列的。一般将Lock维护的队列称作syn queue，将Condition维护的队列称作condition queue。
这两个队列的协作如下:
- syn queue按照顺序维护需要访问共享资源的多个线程，每次只有队列最前端的线程才能获取资源；
- 当一个线程获取到资源后，却发现依赖资源的条件不成立时，就会被挂起并移到对应的condition queue中去；
- 当依赖资源的条件成立后，该线程就会被唤醒，并从condition queue再移至syn queue中。
上面一直将Lock和Condition当做两个概念来说，其实，它们在java中仅仅是两个接口，实现了这两个接口的类是AbstractQueuedSynchronizer，而一些具体的Lock则是基于AbstractQueuedSynchronizer实现的。
这里以ReentrantLock为例，实现的结构类似下面这样子：
class AbstractQueuedSynchronizer
//syn queue
class ConditionObject implements Condition
...
class ReentrantLock implements Lock
class Sync extends AbstractQueuedSynchronizer
这里AbstractQueuedSynchronizer实现的syn queue仅用注释的形式标识了下，详细说明可参见Java AbstractQueuedSynchronizer源码阅读1-基于队列的同步器框架，condition queue则是在AbstractQueuedSynchronizer的内部类ConditionObject中实现的。
Lock的一个具体实现ReentrantLock使用了AbstractQueuedSynchronizer来实现锁的机制。
从这里可以看到，ConditionObject是作为AbstractQueuedSynchronizer的内部类来实现的，这表示，得首先有一个AbstractQueuedSynchronizer的实例，才能新建一个ConditionObject。这更进一步说明了，Condition存在的前提是必须有Lock。
介绍完Lock&Condition之后，本文再提一下另外两个有关的概念synchronized&Object monitor methods。
synchronized&Object monitor methods
synchronized：Java关键字，可用来给对象、方法或代码块加锁。被它锁定的方法或代码块，同一时刻最多只能有一个线程执行这段代码。
Object monitor methods：三个方法：wait()、notify()、notifyAll()，以下为三个方法在java中的部分注释
wait()
Causes the current thread to wait until either another thread invokes the notify() method or the notifyAll() method for this object, or a specified amount of time has elapsed.
The current thread must own this object's monitor.
notify()
Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened.
notifyAll()
Wakes up all threads that are waiting on this object's monitor.
可以看到，synchronized和Lock在功能上类似，都可以保证多线程对一段代码的顺序执行；Object monitor methods则和Condition类似，前者在某个object上进行等待和唤醒，而后者在某个条件上进行等待和唤醒。
java其实是先有的synchronized&Object monitor methods，后有的Lock&Condition。
引用一下java的注释对二者的关系进行下说明：
Lock
Lock implementations provide more extensive locking operations than can be obtained using synchronized methods and statements. They allow more flexible structuring, may have quite different properties, and may support multiple associated Condition objects.
Condition
Condition factors out the Object monitor methods (wait, notify and notifyAll) into distinct objects to give the effect of having multiple wait-sets per object, by combining them with the use of arbitrary Lock implementations.Where a Lock replaces the use of synchronized methods and statements, a Condition replaces the use of the Object monitor methods.
总之，Lock&Condition比synchronized&Object monitor methods支持更多的功能，但是同时也承担更多风险。下面简单说两个例子。
Lock&Condition支持更多的功能
Lock&Condition支持线程等待的超时和中断，这可以避免线程因为某些原因（如IO等待或是调用了sleep()方法）长期占有锁而不释放。
Lock&Condition可支持读者写者模型中，多个读者可同时获取锁的情况。
Lock&Condition承担更多的风险
synchronized不需要用户手动释放锁，由JVM自动释放；Lock则必须要用户手动释放锁，如果处理不慎，就有可能导致死锁。
