java源码分析--Lock与Condition

Lock与Condition源码解析

Lock与Condition接口位于java.util.concurrent.locks包中，Lock接口：多线程在JDK1.5版本升级时，推出一个接口Lock接口。解决线程安全问题使用同步的形式，(同步代码块，要么同步函数)其实最终使用的都是锁机制。到了后期版本，直接将锁封装成了对象。线程进入同步就是具备了锁，执行完，离开同步，就是释放了锁。在后期对锁的分析过程中，发现，获取锁，或者释放锁的动作应该是锁这个事物更清楚。所以将这些动作定义在了锁当中，并把锁定义成对象。
所以同步是隐示的锁操作，而Lock对象是显示的锁操作，它的出现就替代了同步。
在之前的版本中使用Object类中wait、notify、notifyAll的方式来完成的。那是因为同步中的锁是任意对象，所以操作锁的等待唤醒的方法都定义在Object类中。
而现在锁是指定对象Lock。所以查找等待唤醒机制方式需要通过Lock接口来完成。而Lock接口中并没有直接操作等待唤醒的方法，而是将这些方式又单独封装到了一个对象中。这个对象就是Condition，将Object中的三个方法进行单独的封装。并提供了功能一致的方法 await()、signal()、signalAll()体现新版本对象的好处。
1. 体系结构
在java.util.concurrent包中，有两个很特殊的工具类，Condition和ReentrantLock，使用过的人都知道，ReentrantLock（重入锁）是jdk的concurrent包提供的一种独占锁的实现。ReentrantLock的一个内部类Sync继承了AbstractQueuedSynchronizer，ReentrantLock只不过是代理了该类的一些方法，可能有人会问为什么要使用内部类在包装一层？ 我想是安全的关系，因为AbstractQueuedSynchronizer中有很多方法，还实现了共享锁，Condition等功能，如果直接使ReentrantLock继承它，则很容易出现AbstractQueuedSynchronizer中的API被无用的情况
2. api中方法简介
- void await()：造成当前线程在接到信号或被中断之前一直处于等待状态。
- boolean await(long time, TimeUnit unit)：造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
- long awaitNanos(long nanosTimeout)：造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
- void awaitUninterruptibly()：造成当前线程在接到信号之前一直处于等待状态。
- boolean awaitUntil(Date deadline)：造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。
- void signal() ：唤醒一个等待线程。
- void signalAll() ：唤醒所有等待线程。
2. Condition与ReentranLock使用方式
如下一个例子：

public static void main(String[] args) {
    final ReentrantLock reentrantLock = new ReentrantLock();
    final Condition condition = reentrantLock.newCondition();

    Thread thread1 = new Thread((Runnable) () -> {
            try {
                reentrantLock.lock();
                System.out.println("我要等一个新信号" + this);
                condition.await();
            }
            catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("拿到一个信号！！" +