ReentrantLock底层基于AbstractQueuedSynchronizer实现:
首先ReentrantLock实现了Lock接口,Lock接口是Java中对锁操作行为的统一规范,Lock接口的定义如下:
public interface Lock {
// 获取锁
void lock();
// 获取锁-响应中断
void lockInterruptibly() throws InterruptedException;
// 返回获取锁是否成功状态
boolean tryLock();
// 返回获取锁是否成功状态-响应中断
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 释放锁
void unlock();
// 创建条件变量
Condition newCondition();
}
Lock接口定义的函数不多,接下来ReentrantLock要去实现这些函数,遵循着解耦可扩展设计,ReentrantLock内部定义了专门的组件Sync, Sync继承AbstractQueuedSynchronizer提供释放资源的实现,NonfairSync和FairSync是基于Sync扩展的子类,即ReentrantLock的非公平模式与公平模式,它们作为Lock接口功能的基本实现。
在ReentrantLock中,它对AbstractQueuedSynchronizer的state状态值定义为线程获取该锁的重入次数,state状态值为0表示当前没有被任何线程持有,state状态值为1表示被其他线程持有,因为支持可重入,如果是持有锁的线程,再次获取同一把锁,直接成功,并且state状态值+1,线程释放锁state状态值-1,同理重入多次锁的线程,需要释放相应的次数。
1 Sync
Sync可以说是ReentrantLock的亲儿子,完美的继承了AbstractQueuedSynchronizer,是ReentrantLock的核心,后面的NonfairSync与FairSync都是基于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();
if (c == 0) { // state==0 代表资源可获取
//cas设置state为acquires,acquires传入的是1
if (compareAndSetState(0, acquires)) {
//cas成功,设置当前持有锁的线程
setExclusiveOwnerThread(current);
//返回成功
return true;
}
}
else if (current == getExclusiveOwnerThread()) { //如果state!=0,但是当前线程是持有锁线程,直接重入
//state状态+1
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
//设置state状态,此处不需要cas,因为持有锁的线程只有一个
setState(nextc);
//返回成功
return true;
}
//返回失败
return false;
}
/**
* 释放资源
*/
protected final boolean tryRelease(int releases) {
//state状态-releases,releases传入的是1
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread()) //如果当前线程不是持有锁线程,抛出异常
throw new IllegalMonitorStateException();
//设置返回状态,默认为失败
boolean free = false;
if (c == 0) {//state-1后,如果c==0代表释放资源成功
//返回状态设置为true
free = true;
//清空持有锁线程
setExclusiveOwnerThread(null);
}
//如果state-1后,state还是>0,代表当前线程有锁重入操作,需要做相应的释放次数,设置state值
setState(c);
return free;
}
}
首先Sync实现释放资源的细节(A Q S留给子类实现的tryRelease),然后声明了获取锁的抽象函数(lock),子类根据业务实现,目前看来还是很公平,但是Sync还定义了一个nonfairTryAcquire函数,这个函数是专门给NonfairSync使用的。
Sync逻辑都比较简单,实现了A Q S类的释放资源(tryRelease),然后抽象了一个获取锁的函数让子类自行实现(lock),再加一个偏心的函数nonfairTryAcquire。
2 NonfairSync
在ReentrantLock中支持两种获取锁的策略,分别是非公平策略与公平策略,NonfairSync就是非公平策略。
在说非公平策略前,先简单的说下A Q S(AbstractQueuedSynchronizer)流程,A Q S为加锁和解锁过程提供了统一的模板函数,加锁与解锁的模板流程是,获取锁失败的线程,会进入CLH队列阻塞,其他线程解锁会唤醒CLH队列线程,如下图所示(简化流程):
上图中,线程释放锁时,会唤醒CLH队列阻塞的线程,重新竞争锁,要注意,此时可能还有非CLH队列的线程参与竞争,所以非公平就体现在这里,非CLH队列线程与CLH队列线程竞争,各凭本事,不会因为你是CLH队列的线程,排了很久的队,就把锁让给你。
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* 获取锁
*/
final void lock() {
if (compareAndSetState(0, 1))//cas设置state为1成功,代表获取资源成功
//资源获取成功,设置当前线程为持有锁线程
setExclusiveOwnerThread(Thread.currentThread());
else
//cas设置state为1失败,代表获取资源失败,执行AQS获取锁模板流程,否获取资源成功
acquire(1);
}
/**
* 获取资源-使用的是Sync提供的nonfairTryAcquire函数
*/
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* AQS获取锁模板函数,这是AQS类中的函数
*/
public final void acquire(int arg) {
/**
* 我们只需要关注tryAcquire函数,后面的函数是AQS获取资源失败,线程节点进入CLH队列的细节流程,本文不关注
*/
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
NonfairSync继承Sync实现了lock函数,lock函数也非常简单,C A S设置状态值state为1代表获取锁成功,否则执行A Q S的acquire函数(获取锁模板),另外NonfairSync还实现了A Q S留给子类实现的tryAcquire函数(获取资源),这个被Sync宠幸的幸运儿,直接使用Sync提供的nonfairTryAcquire函数来实现tryAcquire,最后子类实现的tryAcquire函数在A Q S的acquire函数中被使用。
首先A Q S的acquire函数是获取锁的流程模板,模板流程会先执行tryAcquire函数获取资源,tryAcquire函数要子类实现,NonfairSync作为子类,实现了tryAcquire函数,具体实现是调用了Sync的nonfairTryAcquire函数。
接下来,我们再看看Sync专门给NonfairSync准备的nonfairTryAcquire函数逻辑:
/**
* 非公平-获取资源
*/
final boolean nonfairTryAcquire(int acquires) {
//获取当前线程
final Thread current = Thread.currentThread();
//获取当前状态
int c = getState();
if (c == 0) { // state==0 代表资源可获取
//cas设置state为acquires,acquires传入的是1
if (compareAndSetState(0, acquires)) {
//cas成功,设置当前持有锁的线程
setExclusiveOwnerThread(current);
//返回成功
return true;
}
}
//如果state!=0,但是当前线程是持有锁线程,直接重入
else if (current == getExclusiveOwnerThread()) {
//state状态+1
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
//设置state状态,此处不需要cas,因为持有锁的线程只有一个
setState(nextc);
//返回成功
return true;
}
//返回失败
return false;
}
当前线程查看资源是否可获取:
可获取,尝试使用C A S设置state为1,C A S成功代表获取资源成功,否则获取资源失败;
不可获取,判断当线程是不是持有锁的线程,如果是,state重入计数,获取资源成功,否则获取资源失败
3 FairSync
有非公平策略,就有公平策略,FairSync就是ReentrantLock的公平策略。所谓公平策略就是,严格按照CLH队列顺序获取锁,线程释放锁时,会唤醒CLH队列阻塞的线程,重新竞争锁,要注意,此时可能还有非CLH队列的线程参与竞争,为了保证公平,一定会让CLH队列线程竞争成功,如果非CLH队列线程一直占用时间片,那就一直失败(构建成节点插入到CLH队尾,由A S Q模板流程执行),直到时间片轮到CLH队列线程为止,所以公平策略的性能会更差。
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
/**
* 获取锁
*/
final void lock() {
//cas设置state为1失败,代表获取资源失败,执行AQS获取锁模板流程,否获取资源成功
acquire(1);
}
/**
* 获取资源
*/
protected final boolean tryAcquire(int acquires) {
//获取当前线程
final Thread current = Thread.currentThread();
//获取state状态
int c = getState();
if (c == 0) { // state==0 代表资源可获取
//1.hasQueuedPredecessors判断当前线程是不是CLH队列被唤醒的线程,如果是执行下一个步骤
//2.cas设置state为acquires,acquires传入的是1
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
//cas成功,设置当前持有锁的线程
setExclusiveOwnerThread(current);
//返回成功
return true;
}
}
//如果state!=0,但是当前线程是持有锁线程,直接重入
else if (current == getExclusiveOwnerThread()) {
//state状态+1
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
//设置state状态,此处不需要cas,因为持有锁的线程只有一个
setState(nextc);
//返回成功
return true;
}
return false;
}
}
/**
* AQS获取锁模板函数,这是AQS类中的函数
*/
public final void acquire(int arg) {
/**
* 我们只需要关注tryAcquire函数,后面的函数是AQS获取资源失败,线程节点进入CLH队列的细节流程,本文不关注
*/
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
其实我们不难发现FairSync流程与NonfairSync基本一致,唯一的区别就是在C A S执行前,多了一步hasQueuedPredecessors函数,这一步就是判断当前线程是不是CLH队列被唤醒的线程,如果是就执行C A S,否则获取资源失败:
4 Lock的实现
//同步器
private final Sync sync;
//默认使用非公平策略
public ReentrantLock() {
sync = new NonfairSync();
}
//true-公平策略 false非公平策略
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
ReentrantLock默认是使用非公平策略,如果想指定模式,可以通过入参fair来选择,这里就不做过多概述,接下来看看ReentrantLock对Lock的实现:
public class ReentrantLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = 7373984872572414699L;
//同步器
private final Sync sync;
//默认使用非公平策略
public ReentrantLock() {
sync = new NonfairSync();
}
//true-公平策略 false非公平策略
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
/**
* 获取锁-阻塞
*/
public void lock() {
//基于sync实现
sync.lock();
}
/**
* 获取锁-阻塞,支持响应线程中断
*/
public void lockInterruptibly() throws InterruptedException {
//基于sync实现
sync.acquireInterruptibly(1);
}
/**
* 获取资源,返回是否成功状态-非阻塞
*/
public boolean tryLock() {
//基于sync实现
return sync.nonfairTryAcquire(1);
}
/**
* 获取锁-阻塞,支持超时
*/
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
//基于sync实现
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
/**
* 释放锁
*/
public void unlock() {
//基于sync实现
sync.release(1);
}
/**
* 创建条件变量
*/
public Condition newCondition() {
//基于sync实现
return sync.newCondition();
}
}
ReentrantLock对Lock的实现都是基于Sync来做的,有一种神器在手,天下我有的风范。Sync承包了所有事情,为何它如此牛皮,因为Sync上有AbstractQueuedSynchronizer老大哥罩着,下有NonfairSync与FairSync两小弟可差遣,所以成为ReentrantLock的利器也合情合理。