一.前言

hello，everyone，好久不见。最近工作太忙，一直没时间写博客。刚空下来，想了想java里面还有一个比较重要的体系：锁，还没有分享过。本文开始将从JUC包的基础数据结构AbstractQueuedSynchronizer（下文简称为AQS）为切入点开始分析JDK包中的锁机制。AQS是JUC包中许多同步类（Lock、Semaphore、ReentrantLock等）的基石，学好AQS对理解JUC包有重要的作用。本文介绍AQS时将结合ReentrantLock为大家做介绍，希望能够帮助到大家。

二.AQS

AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。本文会从应用层逐渐深入到原理层，并通过ReentrantLock的基本特性和ReentrantLock与AQS的关联，来深入解读AQS相关独占锁的知识点。

本篇文章核心为AQS原理剖析，ReentrantLock仅做简单介绍，后续将会出一个专栏介绍，关注订阅我的java专栏不迷路~

2.1.AQS概览

2.1.1.AQS类框架图

图片来源：tech.meituan.com/2019/12/05/…

2.1.2.核心变量

//双向队列头结点，此节点的线程为占有当前state变量的线程
private transient volatile Node head;

//尾部结点，发生锁竞争时，未抢到锁的线程将会排队到尾部
private transient volatile Node tail;

/**
* 状态变量，AQS通过维护state变量的值来控制临界资源的访问
* 初始化为0表示没有线程占用，如果使用独占锁访问，抢到锁的线程会将state的值加1，可重入锁的实现就是基于此
* 字段，如果线程id等于持有state变量的线程id，则将state加1，后续释放锁时，也是在此处重复减1。后续在
* ReentrantLock中将会演示。
*/
private volatile int state;
复制代码

说明：

AQS通过维护volatile修饰的state变量的值来控制对临界资源的访问，state的访问提供一下几个方法

getState()
setState()

compareAndSetState()【CAS】：设置并比较

//CAS比较并且设置值，又是熟悉的unsafe方法，底层调用C语言方法,利用JMM，在多线程环境下，保证修改的
//值是主存中最新的值
protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

关于CAS的解析可以参考：https://www.jianshu.com/p/ae25eb3cfb5d
在java中常被用来乐观锁的实现
在博主另一篇文章ConcurrentHashMap中也有过介绍：https://juejin.cn/post/6960898411314823204
复制代码

AQS定义两种资源共享方式：

1.Exclusive（独占，只有一个线程能执行，如ReentrantLock）

2.Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。

　　不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：

isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

　　以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

　　再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。

　　一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。

2.1.3.AQS双向队列

图片来源：www.cnblogs.com/waterystone…

//node节点为AQS内部双向队列的基础数据结构
static final class Node {
   	//指示节点正在共享模式下等待的标记
    static final Node SHARED = new Node();
	
		//指示节点正在以独占模式等待的标记
    static final Node EXCLUSIVE = null;

		//表示当前结点已取消调度。当timeout或被中断（响应中断的情况下），会触发变更为此状态，进入该状态后的结点将不会再变化。
    static final int CANCELLED =  1;

		//表示后继结点在等待当前结点唤醒。后继结点入队时，会将前继结点的状态更新为SIGNAL
    static final int SIGNAL    = -1;

		//表示结点等待在Condition上，当其他线程调用了Condition的signal()方法后，CONDITION状态的结点将从等待队列转移到同步队列中，等待获取同步锁
    static final int CONDITION = -2;

		//共享模式下，前继结点不仅会唤醒其后继结点，同时也可能会唤醒后继的后继结点
    static final int PROPAGATE = -3;
	
		//当前节点的等待状态，即为上述的状态值
    volatile int waitStatus;

		//当前节点的前置节点
    volatile Node prev;

		//当前节点的后置节点
    volatile Node next;

		//当前节点的线程
    volatile Thread thread;
		
		//下一个等待节点
    Node nextWaiter;

  	//当前是否为共享模式
    final boolean isShared() {
        return nextWaiter == SHARED;
    }

		//返回前置节点
    final Node predecessor() throws NullPointerException {
        Node p = prev;
        if (p == null)
            throw new NullPointerException();
        else
            return p;
    }

    Node() {    
    }

    Node(Thread thread, Node mode) {    
        this.nextWaiter = mode;
        this.thread = thread;
    }

    Node(Thread thread, int waitStatus) { 
        this.waitStatus = waitStatus;
        this.thread = thread;
    }
}
复制代码

AQS内部通过维护一个双向链表来控制临界资源的访问。头结点为当前拥有访问共享变量权限的线程，后续节点为等待唤醒访问的节点。

2.2.核心方法解析

说了这么多，其实AQS就是一个完整的API库，在JUC包中提供的很多工具类都是基于AQS的资源访问与释放等方法来实现的。

2.2.1.acquire(int)

acquire（int）方法是独占模式下线程获取共享资源的顶层入口，资源获取（加锁）入口。如果获取资源成功，则表示线程拿到state变量的访问权限，则对应线程可以执行当前的业务逻辑；获取失败则将节点入队。下面来看一下代码

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
复制代码

//空方法，此方法让用户可以自定义去控制state变量的访问
protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}
复制代码

private Node addWaiter(Node mode) {
		//以给定模式构造结点。mode有两种：EXCLUSIVE（独占）和SHARED（共享）
    Node node = new Node(Thread.currentThread(), mode);
    
    //尝试快速方式直接放到队尾。
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    //上一步失败则通过enq入队。
    enq(node);
    return node;
}
复制代码

private Node enq(final Node node) {
		//CAS"自旋"，直到成功加入队尾
    for (;;) {
        Node t = tail;
        // 队列为空，创建一个空的标志结点作为head结点，并将tail也指向它。
        if (t == null) { 
            if (compareAndSetHead(new Node()))
                tail = head;
        /正常流程，放入队尾
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}
复制代码

final boolean acquireQueued(final Node node, int arg) {
		//标记是否成功拿到资源
    boolean failed = true;
    try {
    		//标记等待过程中是否被中断过
        boolean interrupted = false;
        //自旋
        for (;;) {
        		//获取前驱节点
            final Node p = node.predecessor();
            /如果前驱是head，即该结点已成老二，那么便有资格去尝试获取资源（可能是老大释放完资源唤醒自己的，当然也可能被interrupt了）。
            if (p == head && tryAcquire(arg)) {
            //拿到资源后，将head指向该结点。所以head所指的标杆结点，就是当前获取到资源的那个结点或null。
                setHead(node);
                // setHead中node.prev已置为null，此处再将head.next置为null，就是为了方便GC回收以前的head结点。也就意味着之前拿完资源的结点出队了！
                p.next = null;
                // 成功获取资源
                failed = false;
                /返回等待过程中是否被中断过
                return interrupted;
            }
            //如果自己可以休息了，就通过park()进入waiting状态，直到被unpark()。如果不可中断的情况下被中断了，那么会从park()中醒过来，发现拿不到资源，从而继续进入park()等待。
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                //如果等待过程中被中断过，哪怕只有那么一次，就将interrupted标记为true
                interrupted = true;
        }
    } finally {
    // 如果等待过程中没有成功获取资源（如timeout，或者可中断的情况下被中断了），那么取消结点在队列中的等待。
        if (failed)
            cancelAcquire(node);
    }
}
复制代码

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
		//拿到前驱的状态
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        //如果已经告诉前驱拿完号后通知自己一下，那就可以安心休息了
        return true;
    if (ws > 0) {
        // 如果前驱放弃了，那就一直往前找，直到找到最近一个正常等待的状态，并排在它的后边。
        //注意：那些放弃的结点，由于被自己“加塞”到它们前边，它们相当于形成一个无引用链，稍后就会被GC回收
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        //如果前驱正常，那就把前驱的状态设置成SIGNAL，告诉它拿完号后通知自己一下。有可能失败，人家说不定刚刚释放完呢！
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}
复制代码

private final boolean parkAndCheckInterrupt() {
	//调用park()使线程进入waiting状态
    LockSupport.park(this);
    //如果被唤醒，查看自己是不是被中断的。Thread.interrupted()会清除当前线程的中断标记位
    return Thread.interrupted();
}
复制代码

看完源码总结一下

调用自定义同步器的tryAcquire()尝试直接去获取资源，如果成功则直接返回；
没成功，则addWaiter()将该线程加入等待队列的尾部，并标记为独占模式；
acquireQueued()使线程在等待队列中休息，有机会时（轮到自己，会被unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。

图片来源：www.cnblogs.com/waterystone…

2.2.2. release(int)

与acquire（int）方法对应，release(int)是独占模式下线程释放共享资源的顶层入口，资源释放（解锁）入口。如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。下面来看一下源码

public final boolean release(int arg) {
    if (tryRelease(arg)) {
    		//找到头结点
        Node h = head;
        if (h != null && h.waitStatus != 0)
        		//唤醒等待队列里的下一个线程
            unparkSuccessor(h);
        return true;
    }
    return false;
}
复制代码

//同理为空方法，由对应的实现类来实现
protected boolean tryRelease(int arg) {
    throw new UnsupportedOperationException();
}
复制代码

private void unparkSuccessor(Node node) {
    //这里，node一般为当前线程所在的结点。
    int ws = node.waitStatus;
    //置零当前线程所在的结点状态，允许失败。
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);
    //找到下一个需要唤醒的结点s
    Node s = node.next;
    /如果为空或已取消
    if (s == null || s.waitStatus > 0) {
        s = null;
        // 从后向前找。
        for (Node t = tail; t != null && t != node; t = t.prev)
						//从这里可以看出，<=0的结点，都是还有效的结点。
            if (t.waitStatus <= 0)
                s = t;
    }
    //唤醒
    if (s != null)
        LockSupport.unpark(s.thread);
}
复制代码

release的逻辑相对来说比较简单，将头结点置空等待GC，往后寻找未被取消的节点，waitStatus<=0的节点，将其唤醒作为头结点，获取state的访问权限。

2.2.3.acquireShared(int)

此方法是共享模式下线程获取共享资源的顶层入口。它会获取指定量的资源，获取成功则直接返回，获取失败则进入等待队列，直到获取到资源为止，整个过程忽略中断。下面来看一下源码

public final void acquireShared(int arg) {
//AQS已经把其返回值的语义定义好了：负值代表获取失败；0代表获取成功，但没有剩余资源；正数表示获取成功，
//还有剩余资源，其他线程还可以去获取。尝试获取资源，成功则直接返回
tryAcquireShared()
    if (tryAcquireShared(arg) < 0)
    失败则通过doAcquireShared()进入等待队列，直到获取到资源为止才返回
        doAcquireShared(arg);
}
复制代码

//同理业务侧自己实现
protected int tryAcquireShared(int arg) {
    throw new UnsupportedOperationException();
}
复制代码

private void doAcquireShared(int arg) {
		//加入队列尾部
    final Node node = addWaiter(Node.SHARED);
    //是否成功标志
    boolean failed = true;
    try {
    //等待过程中是否被中断过的标志
        boolean interrupted = false;
        for (;;) {
        		//前驱
            final Node p = node.predecessor();
         //如果到head的下一个，因为head是拿到资源的线程，此时node被唤醒，很可能是head用完资源来唤醒自己的
            if (p == head) {
            		//尝试获取资源
                int r = tryAcquireShared(arg);
                //成功
                if (r >= 0) {
                    setHeadAndPropagate(node, r);
                    p.next = null; // help GC
                    /如果等待过程中被打断过，此时将中断补上。
                    if (interrupted)
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }
            //判断状态，寻找安全点，进入waiting状态，等着被unpark()或interrupt()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}
复制代码

private void setHeadAndPropagate(Node node, int propagate) {
    Node h = head; // Record old head for check below
    //head指向自己
    setHead(node);
    //如果还有剩余量，继续唤醒下一个邻居线程
    if (propagate > 0 || h == null || h.waitStatus < 0 ||
        (h = head) == null || h.waitStatus < 0) {
        Node s = node.next;
        if (s == null || s.isShared())
            doReleaseShared();
    }
}
复制代码

整体逻辑与入队独占锁一致

跟独占模式比，还有一点需要注意的是，这里只有线程是head.next时（“老二”），才会去尝试获取资源，有剩余的话还会唤醒之后的队友。那么问题就来了，假如老大用完后释放了5个资源，而老二需要6个，老三需要1个，老四需要2个。老大先唤醒老二，老二一看资源不够，他是把资源让给老三呢，还是不让？答案是否定的！老二会继续park()等待其他线程释放资源，也更不会去唤醒老三和老四了。独占模式，同一时刻只有一个线程去执行，这样做未尝不可；但共享模式下，多个线程是可以同时执行的，现在因为老二的资源需求量大，而把后面量小的老三和老四也都卡住了。当然，这并不是问题，只是AQS保证严格按照入队顺序唤醒罢了（保证公平，但降低了并发）

2.2.4. releaseShared()

反向释放共享锁

public final boolean releaseShared(int arg) {
		//尝试释放资源
    if (tryReleaseShared(arg)) {
    		//唤醒后继结点
        doReleaseShared();
        return true;
    }
    return false;
}
复制代码

private void doReleaseShared() {
   
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;    
                    //唤醒后继
                unparkSuccessor(h);
            }
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;               
        }
        // head发生变化
        if (h == head)                  
            break;
    }
}
复制代码

此方法的流程也比较简单，一句话：释放掉资源后，唤醒后继。跟独占模式下的release()相似，但有一点稍微需要注意：独占模式下的tryRelease()在完全释放掉资源（state=0）后，才会返回true去唤醒其他线程，这主要是基于独占下可重入的考量；而共享模式下的releaseShared()则没有这种要求，共享模式实质就是控制一定量的线程并发执行，那么拥有资源的线程在释放掉部分资源时就可以唤醒后继等待结点。例如，资源总量是13，A（5）和B（7）分别获取到资源并发运行，C（4）来时只剩1个资源就需要等待。A在运行过程中释放掉2个资源量，然后tryReleaseShared(2)返回true唤醒C，C一看只有3个仍不够继续等待；随后B又释放2个，tryReleaseShared(2)返回true唤醒C，C一看有5个够自己用了，然后C就可以跟A和B一起运行。而ReentrantReadWriteLock读锁的tryReleaseShared()只有在完全释放掉资源（state=0）才返回true，所以自定义同步器可以根据需要决定tryReleaseShared()的返回值。

三.ReentrantLock简介及使用

3.1.介绍

ReentrantLock意思为可重入锁，指的是一个线程能够对一个临界资源重复加锁。常被用来与Synchronized关键字做对比。本节将针对前文对AQS的原理的讲解进行串联，帮助大家理解AQS在ReentrantLock中起到的作用。

Synchronized与ReentrantLock区别：juejin.cn/post/684490…

3.1.1.公平锁与非公平锁

ReentrantLock支持两种加锁方式，公平锁与非公平锁。

以排对吃肯德基的场景介绍一下ReentrantLock中公平锁与非公平锁

**公平锁：**我想吃肯德基，看到前面有人在排队，老老实实的排到现有队伍的最后面，等前面的人买完我再买。

非公平锁：：我想吃肯德基，看到前面有人在排队，我不想排，直接插队去买，如果这个时候你下单成功了，那你就可以省去排队时间吃到了肯德基，但是如果下单失败，就老老实实的继续去排队。

	优点	缺点
公平锁	所有的线程都能得到资源，不会饿死在队列中	吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大
非公平锁	可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量	可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死

3.2.ReentrantLock使用

3.2.1.ReentrantLock构造方法

ReentrantLock默认使用非公平锁

//默认构造方法中非公平锁
public ReentrantLock() {
    sync = new NonfairSync();
}

//非公平锁与公平锁自行选择
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
复制代码

/**
 * 非公平锁
 */
static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;

    final void lock() {
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }

    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}

/**
 * 公平锁
 */
static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;

    final void lock() {
        acquire(1);
    }
		
		//尝试加载资源
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                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;
    }
}
复制代码

3.2.2.ReentrantLock加锁与解锁使用

到现在为止大家应该还不清楚ReentrantLock与AQS到底是怎么做关联的

我们先来简单使用一下ReentrantLock

不加锁

public class Demo {
    int count = 1;

    public void add(){
    		this.count ++;
    }

    public static void main(String[] args) throws Exception{
        Demo demo = new Demo();
        ExecutorService executorService = Executors.newFixedThreadPool(30);
        List<Runnable> runnables = new ArrayList<>();
        List<Future<?>> futures = new ArrayList<Future<?>>();
        for (int i = 0; i < 1000; i++) {
            runnables.add(()->{
                demo.add();
            });
        }
        runnables.forEach(e->{
            futures.add(executorService.submit(e));
        });
        //等待所有任务执行完成
        for(Future<?> f : futures) {
            try {
                f.get();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        System.out.println(demo.count);

    }
}


控制台输出：
987
基本上不等于1001
复制代码

加锁

public class Demo {
    ReentrantLock reentrantLock = new ReentrantLock();
    int count = 1;

    public void add(){
        reentrantLock.lock();
        try{
            this.count ++;
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            reentrantLock.unlock();
        }
    }

    public static void main(String[] args) throws Exception{
        Demo demo = new Demo();
        ExecutorService executorService = Executors.newFixedThreadPool(30);
        List<Runnable> runnables = new ArrayList<>();
        List<Future<?>> futures = new ArrayList<Future<?>>();
        for (int i = 0; i < 1000; i++) {
            runnables.add(()->{
                demo.add();
            });
        }
        runnables.forEach(e->{
            futures.add(executorService.submit(e));
        });
        //等待所有任务执行完成
        for(Future<?> f : futures) {
            try {
                f.get();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        System.out.println(demo.count);

    }
}
复制代码

3.2.3.ReentrantLock加锁与解锁解析

从3.2.2.的代码里面可以看到ReentrantLock的加锁与解锁依靠lock()与unlock()方法。我们去看看这两个方法在干什么

1.Lock()方法

public void lock() {
    sync.lock();
}
复制代码

abstract static class Sync extends AbstractQueuedSynchronizer {
		//省略不必要代码
    abstract void lock();
    //省略不必要代码
}
复制代码

查看lock方法实现

有公平锁与非公平锁的实现。

为展示方便，以公平锁实现逻辑为例

//FairSync类
final void lock() {
    acquire(1);
}
复制代码

//资源获取方法
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
复制代码

在FairSync类中还有一个方法tryAcquire

protected final boolean tryAcquire(int acquires) {
		//获取当前线程变量
    final Thread current = Thread.currentThread();
    				//获取共享变量
            int c = getState();
            //未被占用
            if (c == 0) {
            		//公平锁体现，如果没有等待队列，并且CAS设置状态成功，则拿到锁
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            //如果被占用了，但是占用的线程是当前线程，则将state加1，可重入锁的体现
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
}
复制代码

发现他是一个覆盖方法，与上文讲的业务侧实现的机制一致。

protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}
复制代码

到此我们将ReentrantLock方法与AQS的方法关联起来了，下面我们来梳理一下公平锁的加锁的步骤

2.unlock()方法

//ReentrantLock方法
public void unlock() {
    sync.release(1);
}
复制代码

//AQS内部方法
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}
复制代码

3.2.4.公平锁与非公平锁实现差异

我们知道ReentrantLock是独占锁，那么里面的公平锁与非公平锁的差异点在哪里呢？

不看源码，我们结合上文对AQS与公平锁实现的代码的解析大家觉得能在哪里体现呢？

肯定是lock（）方法，公平锁中lock方法发现如果共享变量被非当前线程的线程给占用了，并且已经有线程在排队了，那么就老老实实的去排队了。我们回到肯德基那张图，非公平锁知道state被占用的情况下，并且有线程在排队时，会直接尝试插队。ok，带着这个思路我们看一下非公平锁的实现

final void lock() {
		//第一次插队，不管当前state是否被占用，先cas一次碰运气看看能不能抢到资源访问的权限
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}
复制代码

protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
}
复制代码

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;
}
复制代码

非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了。
非公平锁在 CAS 失败后，和公平锁一样都会进入到 tryAcquire 方法，在 tryAcquire 方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。