JAVA并发之ReentrantLock源码（一）

　　离上一篇AQS概述已经很久惹，期间也看了一点ReentrantLock、CountdownLantch等的源码，不过并没有看的很深入，也没有把我的理解都记录下来。今天简单的看过线程池之后，就准备对ReentrantLock做一个源码分析，来看看这个lock是怎么做到让多个线程同步的。本文主要是ReentrantLock源码层面的叙述，不会深入到AQS中已经构造好的方法。

1.reentrantlock和sychronized对比：

　　reentrantlock可重入，可以实现公平锁、非公平锁，可以生成多个condition， condition.await signal signAll，获取锁时可以设置超时时间tryLock(long timeout, TimeUnit unit)。

　　sychronized 可重入，非公平锁，锁变量只能有一个，通过锁变量的wait notify notifyAll()通信。

　　对于可重入锁，公平/非公平锁将会在下面的源码分析中做一个总结。在此不单独解释。

2、Sync成员变量：

　　ReentrantLock中就一个成员变量：sync，是继承AQS类实现的，同时有两个实现类，NonfairSync（非公平锁）、FairSync（公平锁）。

    private final Sync sync;

    abstract static class Sync extends AbstractQueuedSynchronizer{
        ...
    }

    static final class NonfairSync extends Sync {
    　　...
    }

    static final class FairSync extends Sync {
    　　...
    }

3、主要方法：

　　3.1 构造方法：

    public ReentrantLock() {
        sync = new NonfairSync();
    }
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

　　很简单的两个构造函数，默认的构造函数，如果需要创建公平锁可以传入一个boolean值，true代表构造公平锁。 

　　3.2 加锁方法实现（lock.lock）：

　　由于锁有两种，因此lock方法的实现也有两种：

    //reentrantlock
    public void lock() {
        sync.lock();
    }
    //fairSync
    final void lock() {
        acquire(1);
    }
    //NonfairSync
    final void lock() {
        if (compareAndSetState(0, 1))//非公平锁先尝试获取资源（cas设置state为1）
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }

　　调用ReentrantLock的lock()方法其实是调用NonfairSync或fairSync中的lock方法，其中acquire()方法是AQS底层实现的，主要进行tryAcquire，如果try失败，则会把线程扔到CLH队列中“排队”等待。

　　我们再来看看ReentrantLock中是怎么实现AQS需要子类实现的tryAcquire方法的吧：

    //fairSync
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {//如果CLH队列中没有线程在等待并且尝试将资源state设置成1就将占有者设置成当前线程并返回成功
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {//可重入判断，如果占有者是当前线程也会尝试成功
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }

    //NonFairSync
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);//这边再套一个非公平尝试获取资源的目的是为了reentrantlock中的tryLock方法直接可以调用
    }
    final boolean nonfairTryAcquire(int acquires) {//大致和公平锁的实现一样
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (compareAndSetState(0, acquires)) {//这里是唯一不同的，非公平锁不会管是否有线程在排队中，直接尝试获取资源
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }

　　同样实现了两套tryAcquire，看完这两个方法，关于锁公平与非公平的如何实现的也基本清楚了：

　　公平锁lock的实现就是直接获取资源（acquire），上一节中我们知道了acquire是AQS的一个重要方法，用于获取资源，如果获取不到就会进入CLH队列中“排队”。（注：对于公平锁获取资源时，如果有等待队列，当前线程会直接进入队列中“排队”）

　　非公平锁呢，则是很“不客气”的先用当前线程企图去获取资源，打个不恰当的比方就像排队看病时，一个人大摇大摆的以为自己是全世界的中心（就好像cpu把时间片分配给某个线程），即时门外有一群人在排队，他也走到房间里面，如果医生刚好没在看病（资源可以被获取到），那么他就直接插队成功啦！如果医生再给别的病人看病呢，他就乖乖的到门外去排队等啦。非公平锁可以减少线程状态的切换，因为刚好时间片分给某个线程时，这个线程就不需要再排队阻塞了，可以直接运行。

　　我们再看一个ReentrantLock与lock有关的方法：

    public boolean tryLock() {
        return sync.nonfairTryAcquire(1);
    }

    public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
        return sync.tryAcquireNanos(1, unit.toNanos(timeout));
    }

　　当使用者调用tryLock方法时，并不在意CLH队列是否有节点在等待，用户只关心能否获得资源，占有这把锁，因此不论公平还是非公平锁都是调用上文中的nonfairTryAcquire()方法，提及下面一个带超时时间的方法只是为了进一步说明文章开头ReentrantLock与sychronized的不同。

　　3.3 释放锁实现（lock.unlock）：

　　unlock()方法其实比lock更简单，因为不论公平还是非公平，释放锁只需要把占领锁的证明给“清除”掉就好啦，具体可以看下面的代码：

    public void unlock() {
        sync.release(1);
    }
    //release低层会先调用tryRelease方法
    protected final boolean tryRelease(int releases) {
        int c = getState() - releases;
        if (Thread.currentThread() != getExclusiveOwnerThread())//你都不是拥有我的线程，凭什么释放我？我要报警啦！
            throw new IllegalMonitorStateException();
        boolean free = false;
        if (c == 0) {//判断是否资源都减完了，到0才说明重入的次数和释放的次数是一样的
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }

　　在释放锁的时候不使用CAS修改state的原因大概是锁是独占的，不会有其他线程同时将state的状态改变掉。

　　3.4 其余方法：

　　其余的一些方法基本都是获取AQS底层的一些状态，比如获取锁的占有线程、获取CLH队列的长度等等，在此不再展开，因为底层都封装好了，在同步器中只需调用底层方法就好。

4、小结：

　　原以为很高深的ReentrantLock就这么简单的实现啦，主要还是AQS的功劳，减少了开发这样简便易用的同步工具的代码量。

　　ReentrantLock的其余一些方法基本就是判断是否公平、判断当前队列是否有等待的线程等简单的方法，看方法名就很容易理解，代码也很简洁。就不在展开了。

　　emmm，上一次开了一个JUC包学习的坑，叙述了AQS的一些设计，但是对于源码还没有详细的叙述，下一章应该会配合ReentrantLock用到的AQS方法，对AQS源码进行部分解析，希望不会太监吧QAQ。