文章目录
1. Lock接口
1.1 引入
Lock接口是Jdk 5之后Java所提供的用于显式的获取和释放锁的接口，接口的定义如下：
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
它的实现类有常用的ReentrantLock、ReentrantReadWriteLock等，如下所示：
Lock接口相对于sychronized关键字来实现线程同步的优势在于：
- 尝试非阻塞的获取锁：当前线程尝试获取锁，如果这一时刻没有被其他的线程获取到，那么该线程可以成功获取并持有锁
- 能被中断的获取锁：获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同时锁将会被释放
- 超时获取锁：在指定的截止时间之前获取锁，如果截止时间到了仍然没有获取到锁，则返回
1.2 API
Lock接口中定义的关于锁的获取的释放的方法如下所示：
-
lock()：获取锁 -
lockInterruptibly()：可中断地获取锁，在获取锁的过程中可响应中断 -
tryLock()：尝试非阻塞的获取锁，调用该方法后立即返回。如果能够获取到锁，返回true；否则返回false -
tryLock(long time, TimeUnit unit)：超时的获取锁，当前线程会在以下三种情况下返回：- 当前线程在超时时间内获取到了锁
- 当前线程在超时时间内被中断
- 超时时间结束，返回false
-
unlock()：释放锁 -
Condition newCondition：获取等待通知组件，该组件和当前线程绑定，当前线程只有获取到了锁，才能调用该组件的wait()方法，而调用后，当前线程将释放锁
2. 队列同步器
2.1 概念
队列同步器（AbstractQueuedSychronizer，AQS）是一个阻塞式锁和相关的同步器工具的框架。Lock锁通过在锁的实现中聚合同步器，利用同步器来实现锁的语义。其他同步组件的基本框架，例如Semaphore、CountDownLatch、CyclicBarrier等也是依赖于AQS实现的。
AQS通过在类中定义一些和同步相关的抽象方法来作为父类使用，其他子类通过继承它并实现其中的抽象方法来实现自定义同步组件。子类通常作为自定义同步组件的静态内部类实现，用户在使用同步组件时不会接触到具体的子类，组件中的方法的实现会代理到子类上。
AQS中使用了state来表示资源的状态（独占模式和共享模式），子类使用如下的方法来维护state，进而来控制如何获取和使用锁：
getState()：获取state状态setState()：设置state状态compareAndSetState()：通过CAS机制来设置state状态
独占模式表示只有一个线程可以访问资源。共享模式表示资源允许被多个线程访问。
它的定义如下：
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
// 队列的head和tail节点，同步状态state都被volatile修饰，保证修改的可见性
private transient volatile Node head;
private transient volatile Node tail;
private volatile int state;
......
}
类中定义的抽象方法大致上分为三类：独占式获取与释放同步状态、共享式获取与释放同步状态和查询同步队列中的等待线程情况 ，例如：
protected boolean tryAcquire(int arg)：独占式获取同步状态，首先查询当前状态并判断同步状态是否符合预期，然后再通过CAS设置同步状态protected boolean tryRelease(int arg)：独占式释放同步状态，等待获取同步状态的线程将有机会获取同步状态protected int tryAcquireShared(int arg)：共享式获取同步状态，返回大于等于0的值，表示获取成功；否则，获取失败protected boolean tryReleaseShared(int arg)：共享式释放同步状态protected boolean isHeldExclusively()：当前同步器是否在独占模式下被线程占用
子类中需要实现上述的方法。如果子类中实现了上述的方法，那么就可以使用它们来获取和释放锁，例如：
-
获取锁
// 如果获取锁失败 if(!tryAcquire(arg)){ // 入队，可以选择阻塞当前线程 } -
释放锁
// 如果释放锁成功 if(tryRelease(arg)){ // 让阻塞线程恢复运行 }
2.2 目标
AQS要实现的功能目标是：
- 阻塞版本获取锁额acquire方法和非阻塞版本的尝试获取锁的tryAcquire方法
- 获取锁超时机制
- 通过打断取消机制
- 独占机制与共享机制
- 条件不满足时的等待机制
2.3 设计思想
AQS的设计思想也是非常直观的，它获取锁时会不断的自旋，直到state值为0表示可以获取锁，如下所示：
while(state 状态不允许获取) {
if(队列中还没有此线程) {
入队并阻塞
}
}
当前线程出队
释放锁时会唤醒等待队列中的其他线程，如下所示：
if(state 状态允许了) {
恢复阻塞的线程(s)
}
核心在于如何原子性的维护state、如何控制阻塞和唤醒线程，以及如何维护线程的等待队列。
-
state使用volatile关键字修饰，并且配合CAS机制来保证其修改时的原子性；state使用了32bit的int型数据来维护同步状态
-
AQS使用了park和unpark来控制线程的阻塞和唤醒，可以先park后unpark，当前相反的操作也是可以的，而且park线程还可以被打断
-
等待队列采用了不支持优先级的FIFO队列，并借鉴了单向无锁的CLH队列
CLH（Craig, Landin, and Hagersten ）队列拥有head和tail两个指针节点，它们都使用volatile修饰，每个节点有state维护节点状态。如下所示：
CLH锁是一种自旋锁，它的优点是快速、无阻塞。入队了出队的操作示意如下所示：
// 入队 do { // 原来的 tail Node prev = tail; // 用 cas 在原来 tail 的基础上改为 node } while(tail.compareAndSet(prev, node)) // 出队 // prev 是上一个节点 while((Node prev=node.prev).state != 唤醒状态) { } // 设置头节点 head = node;CLH锁即Craig, Landin, and Hagersten (CLH) locks。CLH锁是一个自旋锁。能确保无饥饿性。提供先来先服务的公平性。它也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程仅仅在本地变量上自旋，它不断轮询前驱的状态，假设发现前驱释放了锁就结束自旋。
3. 自定义同步器
前面讲到，AQS通过在类中定义一些和同步相关的抽象方法来作为父类使用，其他子类通过继承它并实现其中的抽象方法来实现自定义同步器。因此，我们可以通过实现上述的方法来自定义一个同步器，完成锁的获取的释放。
首先，自定义同步器要继承AbstractQueuedSychronizer类，然后重写其中的tryAcquire()和tryRelease()来时间锁的获取和释放，这里我们以非公平锁的模式进行说明。
final class MySync extends AbstractQueuedSychronizer｛
@Override
protected boolean tryAcquire(int acquires){
// 获取锁的逻辑
}
@Override
protected boolean tryRelease(int acquires){
// 释放锁的逻辑
}
@Override
protected boolean isHeldExclusively(){
//
}
}
那么tryAcquire方法的实现逻辑如何实现呢？首先需要判断传入的acquires是否为1，即判断当前的锁是否已经被其他线程占用。如果已经被占用，那么直接返回false；否则，通过cas机制来设置state，并且设置当前线程为锁的占有线程，最后返回true。整体的实现逻辑如下所示：
@Override
protected boolean tryAcquire(int acquires){
if(acquires == 1){
if(compareAndSetState(0, 1)){
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
}
return false;
}
知道了获取锁的逻辑，那么释放锁的逻辑就简单了。首先判断传入的acquires是否为1来判断是否持锁线程是否要释放锁、如果不等于1，直接返回false；否则进入释放锁的逻辑。释放锁的逻辑中，首先判断state是否为0，如果为0抛IllegalMonitorStateException异常；否则，先将锁的持有线程置为null，然后修改state值为0，表示锁将被释放，最后返回true。整体的实现逻辑如下：
@Override
protected boolean tryRelease(int acquires) {
if(acquires == 1) {
if(getState() == 0) {
throw new IllegalMonitorStateException();
}
setExclusiveOwnerThread(null);
setState(0);
return true;
}
return false;
}
isHeldExclusively()只需要判断state的值是否为1，如果为1，表示当前线程为持锁线程，否则表示锁还没有被获取。
@Override
protected boolean isHeldExclusively() {
return getState() == 1;
}
自定义同步器完成后，就可以使用它自定义锁，锁中方法的实现直接代理到同步器上即可。
4. ReentrantLockd原理
前面通过自定义的同步器知道了，如何通过继承AQS并实现其中的方法来自定同步器，进而实现同步组件的定制。下面来看一下JDK中Lock接口的实现类中自定义同步器的实现逻辑。RnentrantLock的类继承图如下所示：
ReentrantLock中的静态内部类Sync继承了AQS，作为ReentrantLock的同步器使用，Sync又有两个子类分别实现公平模型个非公平模式。Sync的源码实现如下：
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
// 抽象的加锁方法
abstract void lock();
// 非公平锁的获取
final boolean nonfairTryAcquire(int acquires) {
// 获取当前的线程
final Thread current = Thread.currentThread();
// 获取同步状态值
int c = getState();
// 如果同步状态为0，那么当前线程可以获取锁
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
// 如果当前线程已经获取到了锁，那么执行锁重入机制
else if (current == getExclusiveOwnerThread()) {
// 同步状态值加1
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
// 锁的释放，和前面自定义同步器中锁的释放逻辑一致
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// 如果c值为0，表示当前线程释放锁
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
// 否则，只是当前线程重入计数减1
setState(c);
return free;
}
protected final boolean isHeldExclusively() {
// 判断持锁线程是否是当前线程
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {
return getState() != 0;
}
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // reset to unlocked state
}
}
公平锁和非公平锁只有两处不同：
- 非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了
- 非公平锁在 CAS 失败后，和公平锁一样都会进入到 tryAcquire 方法，在 tryAcquire 方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。
公平锁和非公平锁就这两点区别，如果这两次 CAS 都不成功，那么后面非公平锁和公平锁是一样的，都要进入到阻塞队列等待唤醒。相对来说，非公平锁会有更好的性能，因为它的吞吐量比较大。当然，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。
下面以非公平锁为例说明ReentrantLock中锁的获取和释放的源码实现。非公平锁对应的类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);
}
}
4.1 加锁原理
首先，从ReentrantLock的无参构造方法中可以看出，ReentrantLock默认使用的是非公平锁，当然也可以通过另一个构造方法显式使用公平锁。
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
假设，此时Thread-0持有锁并且没有其他的线程竞争锁，也没有当前线程进行锁重入，所以state值为1，如下所示：
如果此时有新的线程Thread-1也要来竞争锁，那么它会使用CAS尝试将state值由0改为1。但是此时锁已经被Thread-0持有，state值为1，所以执行失败。
final void lock() {
// 尝试使用CAS将state从0修改为1，仅尝试一次，成功则获得独占锁
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
// 失败
acquire(1);
}
然后会进入到tryAcquire逻辑再次尝试获取锁，但此时state仍为1，依然获取失败。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
// 当 tryAcquire 返回为 false 时, 先调用 addWaiter, 接着 acquireQueued
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
其中tryAcquire实现如下：
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
// 非公平模式下尝试获取锁
final boolean nonfairTryAcquire(int acquires) {
// 首先获取当前线程
final Thread current = Thread.currentThread();
// 获取state的值
int c = getState();
// 如果此时state为0，表示没有持锁线程存在
if (c == 0) {
// 使用cas尝试将0修改为1
// 此时，如果多个线程同时进入，CAS操作会确保，只有一个线程修改成功
if (compareAndSetState(0, acquires)) {
// 并且设置当前线程为持锁线程，独占模式
setExclusiveOwnerThread(current);
// 返回true
return true;
}
}
// 如果当前线程就是持锁线程，执行锁重入
else if (current == getExclusiveOwnerThread()) {
// 计数器加1
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
// volatile写，保证内存可见性
setState(nextc);
return true;
}
// 如果锁已经被其他的线程持有，竞争失败，返回调用处
return false;
}
tryAcquire执行失败后，Thread-1不再尝试获取锁，而且直接进入等待队列，等待被唤醒。此时，接着进入到addWaiter逻辑，构造等待队列（Node队列），如下所示：
Node节点上的数字表示waitStatus状态，0为默认正常状态；Node是懒惰创建的；第一个Node为哨兵节点。
private Node addWaiter(Node mode) {
// 将当前线程关联到一个Node对象上，模式为独占模式
Node node = new Node(Thread.currentThread(), mode);
// 如果此时tail不为null，说明等待队列中已有线程等待
Node pred = tail;
// 使用cas尝试将node放入等待队列尾部
if (pred != null) {
// 双向链表的插入操作
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 尝试将node加入到AQS
enq(node);
return node;
}
private Node enq(final Node node) {
// 死循环，知道满足条件才返回
for (;;) {
Node t = tail;
// 如果还没有，那么设置head为哨兵节点，状态为0
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
// cas 尝试将node加入AQS队列尾部
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
当前线程进入acquireQueued逻辑：
acquireQueued会在一个死循环中不断尝试获得锁，失败后进入 park 阻塞- 如果自己是紧邻着 head（排第二位），那么再次
tryAcquire尝试获取锁，当然这时 state 仍为 1，失败
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
// 其前驱是头节点，并且再次调用tryAcquire成功获取锁
if (p == head && tryAcquire(arg)) {
// 获取成功将自己作为头节点
setHead(node);
// help GC
p.next = null;
// 返回中断标记 false
failed = false;
// 成功获取锁，返回
return interrupted;
}
//没有得到锁时：
//shouldParkAfterFailedAcquire方法：返回是否需要阻塞当前线程
//parkAndCheckInterrupt方法：阻塞当前线程，当线程再次唤醒时，返回是否被中断
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
// 修改中断标志位
interrupted = true;
}
} finally {
if (failed)
//获取锁失败，则将此线程对应的node的waitStatus改为CANCEL
cancelAcquire(node);
}
}
-
进入
shouldParkAfterFailedAcquire逻辑，将前驱 node，即 head 的 waitStatus 改为 -1，返回 false
-
shouldParkAfterFailedAcquire执行完毕回到acquireQueued，再次tryAcquire尝试获取锁，当然这时state 仍为 1，失败 -
当再次进入
shouldParkAfterFailedAcquire时，这时因为其前驱 node 的 waitStatus 已经是 -1，这次返回true
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
// 获取上一个节点的状态
int ws = pred.waitStatus;
// 前驱节点的waitStatus是SIGNAL，前驱节点释放锁后会唤醒后继节点
if (ws == Node.SIGNAL) {
// 上一个节点都在阻塞, 那么自己也阻塞好了
return true;
}
// > 0 表示取消状态
if (ws > 0) {
// 上一个节点取消, 那么重构删除前面所有取消的节点, 返回到外层循环重试
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
// 这次还没有阻塞
// 但下次如果重试不成功, 则需要阻塞，这时需要设置上一个节点状态为 Node.SIGNAL
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
// 阻塞当前线程
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
-
进入
parkAndCheckInterrupt， Thread-1 park（灰色表示）
再次有多个线程经历上述过程竞争失败，如下所示：
4.2 释放锁原理
Thread-0 释放锁，进入tryRelease流程，如果成功：设置 exclusiveOwnerThread 为 null，state = 0
// 解锁实现
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
// 尝试释放锁
if (tryRelease(arg)) {
// 队列头节点 unpark
Node h = head;
if (
// 队列不为 null
h != null &&
// waitStatus == Node.SIGNAL 才需要 unpark
h.waitStatus != 0
) {
// unpark AQS 中等待的线程, 进入
unparkSuccessor(h);
}
return true;
}
return false;
}
// 只有持锁线程才能释放锁
protected final boolean tryRelease(int releases) {
// state--
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// 支持锁重入, 只有 state 减为 0, 才释放成功
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
当前队列不为 null，并且 head 的 waitStatus = -1，进入unparkSuccessor 流程，找到队列中离 head 最近的一个 Node（没取消的），unpark 恢复其运行，本例中即Thread-1回到Thread-1的acquireQueued流程
如果加锁成功（没有竞争），会设置
- exclusiveOwnerThread为Thread-1，state = 1
- head指向刚刚Thread-1所在的Node，该Node清空Thread
- 原本的head因为从链表断开，而可被垃圾回收
如果这时候有其它线程来竞争（非公平的体现），例如这时有Thread-4来了
private void unparkSuccessor(Node node) {
// 如果状态为 Node.SIGNAL 尝试重置状态为 0
// 不成功也可以
int ws = node.waitStatus;
if (ws < 0) {
compareAndSetWaitStatus(node, ws, 0);
}
// 找到需要 unpark 的节点, 但本节点从 AQS 队列中脱离, 是由唤醒节点完成的
Node s = node.next;
// 不考虑已取消的节点, 从 AQS 队列从后至前找到队列最前面需要 unpark 的节点
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
如果不巧又被Thread-4抢占
- Thread-4被设置为exclusiveOwnerThread，state = 1
- Thread-1 再次进入
acquireQueued流程，获取锁失败，重新进入park阻塞
4.3 可重入原理
由前面nonfairTryAcquire和tryRelease方法的源码可知，ReentrantLock支持可重入是通过以下三个步骤实现的：
- 首先，持锁线程必须是当前想再次获取锁的线程
- 修改state的值，执行一次重入操作值加1
- 当前线程释放锁时，如果state值大于1，表示有锁重入发生，将state值减1；直到state减为0，锁的持锁线程设置为null，锁才算被释放成功
4.4 可打断原理
如果在不可打断模式下执行打断操作，那么被打断的线程仍会在AQS队列中，一直要等到线程获得锁之后才能知道自己已经被打断了。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
parkAndCheckInterrupt内部调用的而是LockSupport工具类中的park方法，最后调用Thread类的静态方法interrupted获取线程的中断标志位。
而且从acquireQueue的实现逻辑可知，即时被打断的线程仍然要获得锁：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
static void selfInterrupt() {
// 重新产生一次中断
Thread.currentThread().interrupt();
}
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null;
failed = false;
// 还是需要获得锁后, 才能返回打断状态
return interrupted;
}
if (
shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt()
) {
// 如果是因为 interrupt 被唤醒, 返回打断状态为 true
interrupted = true;
}
}
} finally {
if (failed)
cancelAcquire(node);
}
}
在不可打断模式中，如果线程在park等待的过程中被中断，那么线程会抛出异常，而不再进入尝试获取锁的for循环中。
public final void acquireInterruptibly(int arg) throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 如果没有获得到锁,进入doAcquireInterruptibly
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
// 可打断的获取锁流程
private void doAcquireInterruptibly(int arg) throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt()) {
// 在 park 过程中如果被 interrupt 会进入此
// 这时候抛出异常, 而不会再次进入 for (;;)
throw new InterruptedException();
}
}
} finally {
if (failed)
cancelAcquire(node);
}
}
4.5 公平锁原理
相比于默认的非公平锁，公平锁的锁获取操作中只是多了一步操作，它会在加入到同步队列前先判断当前节点是否有前驱节点，如果有方法返回true，表示有线程比当前线程更早的请求获取锁。因此，只有等到前面的线程获取并释放锁之后，该线程才能去尝试获取锁。
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 判断是否有前驱节点
// 如果没有前驱节点，并且成功使用CAS将state从0修改为1，将锁的持有线程置为当前线程
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
// 返回true，表示获取锁成功
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;
}
通常来说，非公平锁的线程切换开销更小。因此，ReentrantLock中默认使用的是非公平锁
