【JDK1.8】JUC.Lock综述

一、前言

前段时间结束了jdk1.8集合框架的源码阅读，在过年的这段时间里，一直在准备JUC(java.util.concurrent)的源码阅读。平时接触的并发场景开发并不很多，但是有网络的地方，就存在并发，所以想找几本书阅读深入一下，看到网上推荐较多的两本书《Java并发编程实战》和《Java多线程编程核心技术》。看了两书的优缺点后，笔者选择了先看后者，据说代码例子较多，书到手后，看完后的印象就是对并发的关键字、几个常见类的api进行了介绍，内容挺早以前，讲的也是不是很深，对Java SE5新加的类介绍很少，只能说对于刚接触并发编程的人来说，还是值得一看的。

二、java.util.concurrent.locks图概览

在JUC的包里面，有一个包专门用于存放锁相关的类，笔者将其中的大部分内容整理进了下面UML中：

具体关系大家可以去看看UML的关系图，顺便介绍个生成UML的工具：PlantUml，UML界的markdown，真的挺好用。

图中要提的是：圆圈里面有个+的关系，代表内部类，笔者为了图片看的更简洁，把ReentrantLock、Semaphore等类中的内部类Sync合到了一起，其实它们是一个类，只不过都叫这个名字。

从图中我们可以看到，关系较为紧密的是AbstractQueuedSynchronizer抽象类，而它则直接依赖了LockSupport这个类，笔者将在后面先分析这个类的源码。

三、基础接口的源码解析

3.1 Lock接口

在JDK1.5以后，添加了Lock接口，它用于实现与Synchronized关键字相同的锁操作，来实现多个线程控制对共享资源的访问。但是能提供更加灵活的结构，可能具有完全不同的属性，并且可能支持多个相关的Condition对象。基本用法如下：

Lock l = ...;
l.lock();
try {
    // 访问被锁保护的资源
} finally {
    l.unlock();
}

下面我们来简单看一下它下面的具体内容：

public interface Lock {
    // 获得锁资源
    void lock();
    // 尝试获得锁，如果当前线程被调用了interrupted则中断，并抛出异常，否则就获得锁
    void lockInterruptibly() throws InterruptedException;
    // 判断能否获得锁，如果能获得，则获得锁，并返回true(此时已经获得了锁)
    boolean tryLock();
    // 保持给定的等待时间，如果期间能拿到锁，则获得锁，同样如果期间被中断，则抛异常
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    // 释放锁
    void unlock();
    // 返回与此Lock对象绑定Condition实例
    Condition newCondition();
}

其中，tryLock只会尝试一次，如果返回false，则走false的流程，不会一直让线程一直等待。

3.2 Condition接口

Condition与Lock要结合使用，使用Condition可以用来实现wait()和notify()/notifyAll()类似的等待/通知模式。与Object对象里不同的是，Condition更加灵活，可以在一个Lock对象里创建多个Condition实例，有选择的进行线程通知，在线程调度上更加灵活。使用Condition注释上的例子：

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 {
            // 当count等于数组的大小时，当前线程等待，直到notFull通知，再进行生产
            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 {
            // 当count为0，进入等待，直到notEmpty通知，进行消费。
            while (count == 0)
                notEmpty.await();
            Object x = items[takeptr];
            if (++takeptr == items.length) takeptr = 0;
            --count;
            notFull.signal();
            return x;
        } finally {
            lock.unlock();
        }
    }
}

可以通过多个线程来调用put和take方法，来模拟生产者和消费者。

我们来换成常规的wait/notify的实现方式：

class BoundedBuffer {
   	private final Object lock;

    public BoundedBuffer(Object lock) {
        this.lock = lock;
    }
    public void put(Object x) {
        try {
            synchronized (items) {
                while (count == items.length) {
                    items.wait();
                }
                items[putptr] = x;
                if (++putptr == items.length) putptr = 0;
                ++count;
                // items.notify();
                items.notifyAll();
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public Object take() {
        try {
            synchronized (items) {
                while (count == 0) {
                    items.wait();
                }
                Object x = items[takeptr];
                if (++takeptr == items.length) takeptr = 0;
                --count;
                // items.notify();
                items.notifyAll();
                return x;
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return null;
    }
}

如果将items.notifyAll()换成items.notify()，在多生产者和多消费者模式情况下，可能出现take唤醒了take的情况，导致生产者在等待消费者消费，而消费者等待生产者生产，最终导致程序无限等待，而用notifyAll()，则唤醒所有的生产者和消费者，不像Condition可以选择性的通知。下面我们来看一下它的源码：

public interface Condition {
    // 让当前线程等待，直到被通知或者被中断
    void await() throws InterruptedException;
    // 与前者的区别是，当等待过程中被中断时，仍会继续等待，直到被唤醒，才会设置中断状态
    void awaitUninterruptibly();
    // 让当前线程等待，直到它被告知或中断，或指定的等待时间已经过。
    boolean await(long time, TimeUnit unit) throws InterruptedException;
    // 与上面的类似，让当前线程等待，不过时间单位是纳秒
    long awaitNanos(long nanosTimeout) throws InterruptedException;
    // 让当前线程等待到确切的指定时间，而不是时长
    boolean awaitUntil(Date deadline) throws InterruptedException;
    // 唤醒一个等待当前condition的线程，有多个则随机选一个
    void signal();
    // 唤醒所有等待当前condition的线程
    void signalAll();
}

3.3 ReadWriteLock接口

读写锁与一般的互斥锁不同，它分为读锁和写锁，在同一时间里，可以有多个线程获取读锁来进行共享资源的访问。如果此时有线程获取了写锁，那么读锁的线程将等待，直到写锁释放掉，才能进行共享资源访问。简单来说就是读锁与写锁互斥。

读写锁比互斥锁允许对于共享数据更大程度的并发。每次只能有一个写线程，但是同时可以有多个线程并发地读数据。ReadWriteLock适用于读多写少的并发情况。

public interface ReadWriteLock {
    // 返回写锁
	Lock writeLock();
    // 返回读锁
	Lock readLock();
}

再看一下源码里提供的示例：

class CachedData {
    Object data;
    volatile boolean cacheValid;
    final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

    void processCachedData() {
        // 获得写锁
        rwl.readLock().lock();
        // 缓存无效，则重写数据
        if (!cacheValid) {
            // 在获得写锁之前，必须先释放读锁
            rwl.readLock().unlock();
            rwl.writeLock().lock();
            try {
                // 重写检查一次，因为其他线程可能在这段时间里获得了写锁，并且修改了状态
                if (!cacheValid) {
                    data = ...
                        cacheValid = true;
                }
                // 在释放写锁之前，通过获取读锁来降级。
                rwl.readLock().lock();
            } finally {
                // 释放写锁
                rwl.writeLock().unlock();
            }
        }
        // cacheValid，直接获取数据，并释放读锁
        try {
            use(data);
        } finally {
            rwl.readLock().unlock();
        }
    }
}

ReentrantReadWriteLock中，读锁可以获取写锁，而返过来，写锁不能获得读锁，所以在上面代码中，要先释放写锁，再获取读锁，具体的源码分析后面再细说。

四、总结

开了个新坑，边看边学。最后谢谢各位园友观看，如果有描述不对的地方欢迎指正，与大家共同进步！