【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中，读锁可以获取写锁，而返过来，写锁不能获得读锁，所以在上面代码中，要先释放写锁，再获取读锁，具体的源码分析后面再细说。
四、总结
开了个新坑，边看边学。最后谢谢各位园友观看，如果有描述不对的地方欢迎指正，与大家共同进步！
腾讯云开发者
