ReentrantLock（公平锁、非公平锁）可重入锁原理

基本使用

ReentrantLock，位于java.util.concurrent包，于JDK1.5引入，一种可重入互斥Lock ，其基本行为和语义与使用synchronized方法和语句访问的隐式监视器锁相同，但具有扩展功能。
ReentrantLock的使用也很简单，在源码注释中可以看到使用的推荐方式：

public void m() {
    lock.lock();  // block until condition holds
    try {
        // ... method body
    } finally {
        lock.unlock()
    }       
}

具体使用代码如下：

package com.starsray.test.lock;
 
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.locks.ReentrantLock;
 
public class TestReentrantLock {
    private final static ReentrantLock lock = new ReentrantLock();
    
    
    static int threadCount = 5;
    static int counter = 0;
    static int threshold = 1000;
    private static final CountDownLatch latch = new CountDownLatch(threadCount);
 
    public static void m() {
        lock.lock();
        try {
            counter++;
        } finally {
            lock.unlock();
        }
    }
    
    
    public static void main(String[] args) throws InterruptedException {
        
        for (int i = 0; i < threadCount; i++) {
            new Thread(() -> {
                for (int j = 0; j < threshold; j++) {
                    m();
                }
                latch.countDown();
            }, "Thread-" + i).start();
        }
        latch.await();
        System.out.println("count:" + counter);
    }
}

源码分析

ReentrantLock由上次成功锁定但尚未解锁的线程拥有。当锁不被另一个线程拥有时，调用lock的线程将返回，成功获取锁。如果当前线程已经拥有锁，该方法将立即返回。可以使用方法isHeldByCurrentThread和getHoldCount来检查。
ReentrantLock除了支持synchronized的语义之外，还支持公平锁和非公平锁的拓展，在非公平锁模式下与synchronized相同，也是其默认的锁模式。构造函数接受一个可选的公平参数，当设置为true时表示为公平锁。
ReentrantLock基于AQS实现，内部维护了一个CLH队列，所谓公平非公平，指的是线程是否按照入队的顺序进行锁的获取。需要注意的是，锁的公平性并不能保证线程调度的公平性。因此，使用公平锁的许多线程之一可能会连续多次获得它，而其他活动线程没有进展并且当前没有持有锁。另请注意，不定时的tryLock()方法不遵守公平设置。如果锁可用，即使其他线程正在等待，它也会成功。
查看ReentrantLock的类图结构，其实现了Lock接口，其中定义了关于锁的一些基本操作，包含了Sync、FairSync、NonfairSync这几个内部类。从名称也可以看出FairSync、NonfairSync分别实现了公平锁和非公平锁，二者同时继承自，作为锁实现的Sync，并且Sync继承自AbstractQueuedSynchronizer。
接下来对ReentrantLock的源码进行分析。

Sync(基础类)

ReentrantLock实现的基础依赖于Sync类，一个静态内部抽象类，继承自AbstractQueuedSynchronizer，使用AQS中的state状态值来记录持有锁的次数，为下面的公平锁和非公平锁扩展定义好了基础框架。
ReentrantLock中关于加锁根据场景有不同的实现，对应的lock方法分别在Lock接口和内部类Sync、FairSync、NonfairSync中进行定义和重载，而解锁的方式统一调用的是AQS中定义的变更状态方法，得益于AQS优秀的设计。如下代码所示：

public void unlock() {
    // 此处release调用为synch子类对象指向Sync继承自AQS的父类方法
    sync.release(1);
}
 
public void lock() {
    // 此处lock方法为sync子类对象各自引用的调用
    sync.lock();
}

AQS中实现了同步队列阻塞以及释放锁的能力，开放了子类关于锁的添加和释放的方法，tryAcquireShared、tryAcquire、tryRelease、tryReleaseShared，因此ReentrantLock中也是如此，由于其为互斥锁实现，因此只用重写tryAcquire、tryRelease方法的实现即可。这在Sync类中分别对应：

// 默认实现了非公平锁的加锁条件
final boolean nonfairTryAcquire(int acquires) {
    // 获取当前线程
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 如果同步状态位为0，当前线程尝试通过CAS去修改状态位
        if (compareAndSetState(0, acquires)) {
            // 如果CAS成功，设置当前线程为独占线程，返回true
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    // 如果不为0，判断当前线程是否为独占线程
    else if (current == getExclusiveOwnerThread()) {
        // 如果再次获取锁，记录重入次数
        int nextc = c + acquires;
        if (nextc < 0) // overflow 溢出
            throw new Error("Maximum lock count exceeded");
        // 更新状态位
        setState(nextc);
        return true;
    }
    // 如果线程首次即没有获得锁，也不满足重入条件，返回false，获取锁失败
    return false;
}
 
// 使用模板方法设计模式，该方法在AQS的release方法中被调用，作为判断是否释放锁状态的前置条件
protected final boolean tryRelease(int releases) {
    // 每次释放锁对状态为进行递减
    int c = getState() - releases;
    // 如果当前线程不是队列首线程，抛出IllegalMonitorStateException异常
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    // 当同步状态位state==0时，返回释放锁成功
    boolean free = false;
    if (c == 0) {
        free = true;
        // 当前独占线程为null，即没有线程占用
        setExclusiveOwnerThread(null);
    }
    // 更新同步状态位为初始值
    setState(c);
    return free;
}

Sync中tryRelease对应为父类AQS中的实现，nonfairTryAcquire对应子类中的公共实现，父类AQS中tryAcquire的实现分别在FairSync和NonfairSync子类中进行实现。

FairSync(公平锁)

由于ReentrantLock基于FIFO的队列来实现线程排队等待，公平锁中的tryAcquire方法，当CPU进行调度时，每次按照队列的排队顺序进行同步状态为值的判断，尝试锁的获取，因此实现了先到先得的公平性。

static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;
 
    final void lock() {
        // 调用AQS的acquire方法，传入参数state值为1
        // 是否将当前线程加入到等待队列中，取决于tryAcquire的返回结果
        // 如果尝试获取锁或者添加到队列失败，将中断当前线程操作
        acquire(1);
    }
 
    // 尝试获取锁的公平锁实现，如果不是队列首线程将获取锁失败
    protected final boolean tryAcquire(int acquires) {
        // 获取当前运行线程
        final Thread current = Thread.currentThread();
        // 获取AQS的同步状态值
        int c = getState();
        if (c == 0) {
            // hasQueuedPredecessors方法的执行结果：如果当前线程之前有排队线程，则为true ，如果当前线程位于队列的头部或队列为空，则为false
            // 如果同步状态为0，并且当前队列没有线程排队，并且CAS修改状态位成功则尝试获取锁成功
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                // 设置当前线程为独占拥有线程
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            // 如果 c != 0，且当前线程为独占线程，记录当前线程重入锁的次数。
            int nextc = c + acquires;
            if (nextc < 0)
                // 冲入次数溢出了，超过了int表示的最大值
                throw new Error("Maximum lock count exceeded");
            // 更新AQS同步状态位的值
            setState(nextc);
            return true;
        }
        return false;
    }
}

NonfairSync(非公平锁)

关于非公平锁的实现也是相当巧妙，基于队列实现公平锁很简单，如何实现非公平锁呢？如下代码所示：

static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;
 
    final void lock() {
        // 在线程入队前先进性一次CAS尝试，如果成功，则将当前线程设置为独占模式的执行线程
        // 其余线程继续保持队列排队等待状态，作者也在注释中说明了锁的公平性并不能保证线程调度的公平性
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            // 如果CAS失败，则进入队列
            acquire(1);
    }
 
    protected final boolean tryAcquire(int acquires) {
        // 调用基础类中的实现
        return nonfairTryAcquire(acquires);
    }
}

总结

• ReentrantLock实现了synchronized相同的语义，并且对其进行了扩展，synchronized借助于操作系统层面互斥信号量来实现互斥锁，ReentrantLock借助于AQS抽象同步队列框架来实现锁。
• 公平锁与非公平锁，二者的区别在于，公平锁直接依赖队列的顺序进行线程的执行与挂起，而非公平锁在CPU进行调度时直接进行一次CAS操作，如果成功则获得调度优先级，失败则进入队列等待。
• 在锁的获取方面使用synchronized的锁往往会被一个线程多次获取，而ReentrantLock提供的锁在线程执释放锁后，如果再次获得锁就需要进入队列等待。

参考资料：

• jdk1.8.0_311 ReentrantLock源码