系列文章目录
Java并发编程技术知识点梳理(第一篇)操作系统底层工作的整体认识
Java并发编程技术知识点梳理(第二篇)并发编程之JMM&volatile详解
Java并发编程技术知识点梳理(第三篇)CPU缓存一致性协议MESI
Java并发编程技术知识点梳理(第四篇)并发编程之synchronized详解
Java并发编程技术知识点梳理(第五篇)抽象队列同步器AQS应用Lock详解
Java并发编程技术知识点梳理(第六篇)并发编程之LockSupport的 park 方法及线程中断响应
Java并发编程技术知识点梳理(第七篇)抽象队列同步器AQS应用之阻塞队列BlockingQueue详解
Java并发编程技术知识点梳理(第八篇)并发编程之CountDownLatch&Semaphore原理与应用
Java并发编程技术知识点梳理(第九篇)并发编程之Atomic&Unsafe魔法类详解
Java并发编程技术知识点梳理(第十篇)Collections之HashMap分析
Java并发编程技术知识点梳理(第十一篇)并发编程之Executor线程池原理与源码解读
Java并发编程技术知识点梳理(第十二篇)并发编程之定时任务&定时线程池
抽象队列同步器AQS应用Lock详解
AQS应用之Lock
Java并发编程核心在于java.util.concurrent包而juc当中的大多数同步器实现都是围绕着共同的基础行为,比如等待队列、条件队列、独占获取、共享获取等,而这个行为的抽象就是基于AbstractQueuedSynchronizer简称AQS,AQS定义了一套多线程访问共享资源的同步器框架,是一个依赖状态(state)的同步器。
ReentrantLock
ReentrantLock是一种基于AQS框架的应用实现,是JDK中的一种线程并发访问的同步手段,它的功能类似于synchronized是一种互斥锁,可以保证线程安全。而且它具有比synchronized更多的特性,比如它支持手动加锁与解锁,支持加锁的公平性。
使用ReentrantLock进行同步
ReentrantLock lock = new ReentrantLock(false);//false为非公平锁,true为公平锁
lock.lock() //加锁
lock.unlock() //解锁
ReentrantLock如何实现synchronized不具备的公平与非公平性呢?
在ReentrantLock内部定义了一个Sync的内部类,该类继承AbstractQueuedSynchronized,对该抽象类的部分方法做了实现;并且还定义了两个子类:
1、FairSync 公平锁的实现
2、NonfairSync 非公平锁的实现
这两个类都继承自Sync,也就是间接继承了AbstractQueuedSynchronized,所以这一个ReentrantLock同时具备公平与非公平特性。
上面主要涉及的设计模式:模板模式-子类根据需要做具体业务实现
AQS具备特性
- 阻塞等待队列
- 共享/独占
- 公平/非公平
- 可重入
- 允许中断
除了Lock外,Java.util.concurrent当中同步器的实现如Latch,Barrier,BlockingQueue等,都是基于AQS框架实现
- 一般通过定义内部类Sync继承AQS
- 将同步器所有调用都映射到Sync对应的方法
AQS内部维护属性volatile int state (32位),state表示资源的可用状态
state三种访问方式:getState()、setState()、compareAndSetState()
AQS定义两种资源共享方式
- Exclusive-独占,只有一个线程能执行,如ReentrantLock
- Share-共享,多个线程可以同时执行,如Semaphore/CountDownLatch
AQS定义两种队列,同步等待队列和条件等待队列
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可,至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等),AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法:
- isHeldExclusively():该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int):独占方式。尝试获取资源,成功则返回true,失败则返回false。
- tryRelease(int):独占方式。尝试释放资源,成功则返回true,失败则返回false。
- tryAcquireShared(int):共享方式。尝试获取资源。负数表示失败;0表示成功,但没有剩余可用资源;正数表示成功,且有剩余资源。
- tryReleaseShared(int):共享方式。尝试释放资源,如果释放后允许唤醒后续等待结点返回true,否则返回false
同步等待队列
AQS当中的同步等待队列也称CLH队列,CLH队列是Craig、Landin、Hagersten三人发明的一种基于双向链表数据结构的队列,是FIFO先入先出线程等待队列,Java中的CLH队列是原CLH队列的一个变种,线程由原自旋机制改为阻塞机制。
条件等待队列
Condition是一个多线程间协调通信的工具类,使得某个,或者某些线程一起等待某个条件(Condition),只有当该条件具备时,这些等待线程才会被唤醒,从而重新争夺锁
AQS源码分析
案例一
public class Juc02_Thread_ReentrantLock {
private static ReentrantLock lock = new ReentrantLock(true);
public static void reentrantLock(){
String threadName = Thread.currentThread().getName();
//默认创建的是独占锁,排它锁;同一时刻读或者写只允许一个线程获取锁
lock.lock();
log.info("Thread:{},第一次加锁",threadName);
lock.lock();
log.info("Thread:{},第二次加锁",threadName);
lock.unlock();
log.info("Thread:{},第一次解锁",threadName);
lock.unlock();
log.info("Thread:{},第二次解锁",threadName);
}
public static void main(String[] args) {
Thread t0 = new Thread(new Runnable() {
@Override
public void run() {
reentrantLock();
}
},"t0");
t0.start();
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
reentrantLock();
}
},"t1");
t1.start();
}
}
案例二(常用场景)
package com.yg.edu.lock.reentrantlock;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
/**
* @author 史凯强
* @date 2021/10/25 12:13
* @desc
**/
public class WorkTask {
int taskCount = 0;
//声明此锁
private Lock lock = new ReentrantLock();
public void makeTask(){
lock.lock();
try{
taskCount++;
}finally {
lock.unlock();
}
}
}
package com.yg.edu.lock.reentrantlock;
import java.util.concurrent.TimeUnit;
/**
* @author 史凯强
* @date 2021/10/25 12:13
* @desc
**/
public class Main {
public static void main(String[] args) {
WorkTask task = new WorkTask();
for(int i=0;i<20;i++) {
new Thread(() -> {
for(int j=0;j<1000;j++){
task.makeTask();
}
},"thread"+i).start();
}
//等待上面的线程都计算完成后,再用main线程取得最终结果值
try {
TimeUnit.SECONDS.sleep(4);
} catch (InterruptedException e) {
e.printStackTrace();
}
//等待所有累加线程都结束
while (Thread.activeCount()>2){
Thread.yield();
}
System.out.println(Thread.currentThread().getName()+"\t 结果是 "+task.taskCount);
}
}
AQS队列同步器的架构组织图
ReentrantLock–>Lock
NonfairSync/FairSync–>Sync–>AbstractQueuedSynchronizer–>AbstractOwnableSynchronizer
NonfairSync/FairSync–>Sync是ReentrantLock的三个内部类
Node是AbstractQueuedSynchronizer的内部类
注意:上边这四条线,对应关系:“子类”–>“父类”
对于ReentrantLock需要掌握以下几点
- ReentrantLock的创建(公平锁/非公平锁)
- 上锁:lock()
- 解锁:unlock()
ReentrantLock的创建
支持公平锁(先进来的线程先执行)
final ReentrantLock lock = new ReentrantLock();
支持非公平锁(后进来的线程也可能先执行)
final ReentrantLock lock = new ReentrantLock(true)
源码如下
ReentrantLock:
/** 同步器:内部类Sync的一个引用 */
private final Sync sync;
/**
* 创建一个非公平锁
*/
public ReentrantLock() {
sync = new NonfairSync();
}
/**
* 创建一个锁
* @param fair true-->公平锁 false-->非公平锁
*/
public ReentrantLock(boolean fair) {
sync = (fair)? new FairSync() : new NonfairSync();
}
上述源代码中出现了三个内部类Sync/NonfairSync/FairSync,这里只列出类的定义,至于这三个类中的具体的方法会在后续的第一次引用的时候介绍。
Sync/NonfairSync/FairSync类定义:
/**
* 该锁同步控制的一个基类.下边有两个子类:非公平机制和公平机制.使用了AbstractQueuedSynchronizer类的
*/
static abstract class Sync extends AbstractQueuedSynchronizer
/**
* 非公平锁同步器
*/
final static class NonfairSync extends Sync
/**
* 公平锁同步器
*/
final static class FairSync extends Sync
上锁:lock()
非公平
具体使用方法:
lock.lock();
下面先介绍一下这个总体步骤的简化版,然后会给出详细的源代码,并在源代码的lock()方法部分给出详细版的步骤。
简化版的步骤:(非公平锁的核心)
基于CAS尝试将state(锁数量)从0设置为1
- A、如果设置成功,设置当前线程为独占锁的线程;
- B、如果设置失败,还会再获取一次锁数量,
- B1、如果锁数量为0,再基于CAS尝试将state(锁数量)从0设置为1一次,如果设置成功,设置当前线程为独占锁的线程;
- B2、如果锁数量不为0或者上边的尝试又失败了,查看当前线程是不是已经是独占锁的线程了,如果是,则将当前的锁数量+1;如果不是,则将该线程封装在一个Node内,并加入到等待队列中去。等待被其前一个线程节点唤醒。
/**
*获取一个锁
*三种情况:
*1、如果当下这个锁没有被任何线程(包括当前线程)持有,则立即获取锁,锁数量==1,之后再执行相应的业务逻辑
*2、如果当前线程正在持有这个锁,那么锁数量+1,之后再执行相应的业务逻辑
*3、如果当下锁被另一个线程所持有,则当前线程处于休眠状态,直到获得锁之后,当前线程被唤醒,锁数量==1,再执行相应的业务逻辑
*/
public void lock() {
sync.lock();//调用NonfairSync(非公平锁)或FairSync(公平锁)的lock()方法
}
final void lock() {
//首先基于CAS将state(锁数量)从0设置为1,如果设置成功,设置当前线程为独占锁的线程;-->请求成功-->第一次插队
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
//如果设置失败(即当前的锁数量可能已经为1了,即在尝试的过程中,已经被其他线程先一步占有了锁),这个时候当前线程执行acquire(1)方法
acquire(1);
}
下面列出NonfairSync:lock()中调用的几个方法与相关属性。
AbstractQueuedSynchronizer:锁数量state属性+相关方法:
注意:state是volatile型的
/**
* 锁数量
*/
private volatile int state;
/**
* 获取锁数量
*/
protected final int getState() {
return state;
}
protected final void setState(int newState) {
state = newState;
}
AbstractOwnableSynchronizer:属性+setExclusiveOwnerThread(Thread t)
/**
* 当前拥有独占锁的线程
*/
private transient Thread exclusiveOwnerThread;
/**
* 设置独占锁的线程为线程t
*/
protected final void setExclusiveOwnerThread(Thread t) {
exclusiveOwnerThread = t;
}
AbstractQueuedSynchronizer:属性+acquire(int arg)
/**
* 获取锁的方法
* @param arg
*/
public final void acquire(int arg) {
//acquire(1)方法首先调用下边的tryAcquire(1)方法,在该方法中,首先获取锁数量状态,
//如果最后在tryAcquire(1)方法中上述的执行都没成功,即请求没有成功,则返回false,继续执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)方法
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
//中断自己
selfInterrupt();
}
在介绍上边这个方法之前,先要说一下AbstractQueuedSynchronizer的一个内部类Node的整体构造,源代码如下:
/**
* 同步等待队列(双向链表)中的节点
*/
static final class Node {
/** Marker to indicate a node is waiting in shared mode */
static final Node SHARED = new Node();
/** 一个标记:用于表明该节点正在独占锁模式下进行等待 */
static final Node EXCLUSIVE = null;
/** 线程被取消了 */
static final int CANCELLED = 1;
/**
* 如果前驱节点的等待状态是SIGNAL,表示当前节点将来可以被唤醒,那么当前节点就可以安全的挂起了
* 否则,当前节点不能挂起
*/
static final int SIGNAL = -1;
/**线程正在等待条件*/
static final int CONDITION = -2;
/**
* waitStatus value to indicate the next acquireShared should
* unconditionally propagate
*/
static final int PROPAGATE = -3;
//值就是前四个int(CANCELLED/SIGNAL/CONDITION/PROPAGATE),再加一个0
volatile int waitStatus;
/**前驱节点*/
volatile Node prev;
/**后继节点*/
volatile Node next;
/**节点中的线程*/
volatile Thread thread;
/**
* Link to next node waiting on condition, or the special
* value SHARED. Because condition queues are accessed only
* when holding in exclusive mode, we just need a simple
* linked queue to hold nodes while they are waiting on
* conditions. They are then transferred to the queue to
* re-acquire. And because conditions can only be exclusive,
* we save a field by using special value to indicate shared
* mode.
*/
Node nextWaiter;
/**
* Returns true if node is waiting in shared mode.
*/
final boolean isShared() {
return nextWaiter == SHARED;
}
/**
* 返回该节点前一个节点
*/
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() {
// Used to establish initial head or SHARED marker
}
Node(Thread thread, Node mode) {
// 用于addWaiter中
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) {
// Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
注意:这里我给出了Node类的完整版,其中部分属性与方法是在共享锁的模式下使用的,而我们这里的ReentrantLock是一个独占锁,只需关注其中的与独占锁相关的部分就好(具体有注释)
AbstractQueuedSynchronizer:acquire(int arg)方法中使用到的两个方法
NonfairSync:tryAcquire(int acquires)
/**
* 试着请求成功
*/
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
/**
* 非公平锁中被tryAcquire调用
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();//获取当前线程
int c = getState();//获取锁数量
if (c == 0) {
//如果锁数量为0,证明该独占锁已被释放,当下没有线程在使用
if (compareAndSetState(0, acquires)) {
//继续通过CAS将state由0变为1,注意这里传入的acquires为1
setExclusiveOwnerThread(current);//将当前线程设置为独占锁的线程
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
//查看当前线程是不是就是独占锁的线程
int nextc = c + acquires;//如果是,锁状态的数量为当前的锁数量+1
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);//设置当前的锁数量
return true;
}
return false;
}
注意:这个方法就完成了"简化版的步骤"中的"A/B/B1"三步,如果上述的请求不能成功,就要执行下边的代码了,
下边的代码,用一句话介绍:请求失败后,将当前线程链入队尾并挂起,之后等待被唤醒。在你看下边的代码的时候心里默记着这句话。
AbstractQueuedSynchronizer:addWaiter(Node mode)
/**
* 将Node节点加入等待队列
* 1)快速入队,入队成功的话,返回node
* 2)入队失败的话,使用正常入队
* 注意:快速入队与正常入队相比,可以发现,正常入队仅仅比快速入队多而一个判断队列是否为空且为空之后的过程
* @return 返回当前要插入的这个节点,注意不是前一个节点
*/
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);//创建节点
/*
* 快速入队
*/
Node pred = tail;//将尾节点赋给pred
if (pred != null) {
//尾节点不为空
node.prev = pred;//将尾节点作为创造出来的节点的前一个节点,即将node链接到为节点后
/**
* 基于CAS将node设置为尾节点,如果设置失败,说明在当前线程获取尾节点到现在这段过程中已经有其他线程将尾节点给替换过了
* 注意:假设有链表node1-->node2-->pred(当然是双链表,这里画成双链表才合适),
* 通过CAS将pred替换成了node节点,即当下的链表为node1-->node2-->node,
* 然后根据上边的"node.prev = pred"与下边的"pred.next = node"将pred插入到双链表中去,组成最终的链表如下:
* node1-->node2-->pred-->node
* 这样的话,实际上我们发现没有指定node2.next=pred与pred.prev=node2,这是为什么呢?
* 因为在之前这两句就早就执行好了,即node2.next和pred.prev这连个属性之前就设置好了
*/
if (compareAndSetTail(pred, node)) {
pred.next = node; //将node放在尾节点上
return node;
}
}
enq(node);//正常入队
return node;
}
AbstractQueuedSynchronizer:enq(final Node node)
/**
* 正常入队
* @param node
* @return 之前的尾节点
*/
private Node enq(final Node node) {
for (;;) {
//无限循环,一定要阻塞到入队成功为止
Node t = tail;//获取尾节点
if (t == null) {
//如果尾节点为null,说明当前等待队列为空
/*
* 基于CAS将新节点(一个dummy节点)设置到头上head去,如果发现内存中的当前值不是null,则说明,在这个过程中,已经有其他线程设置过了。
* 当成功的将这个dummy节点设置到head节点上去时,我们又将这个head节点设置给了tail节点,即head与tail都是当前这个dummy节点,
* 之后有新节点入队的话,就插入到该dummy之后
*/
if (compareAndSetHead(new Node()))
tail = head;
} else {
//这一块儿的逻辑与快速入队完全相同
node.prev = t;
if (compareAndSetTail(t, node)) {
//尝试将node节点设为尾节点
t.next = node;//将node节点设为尾节点
return t;
}
}
}
}
AbstractQueuedSynchronizer:acquireQueued(final Node node, int arg)
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
/*
* 无限循环(一直阻塞),直到node的前驱节点p之前的所有节点都执行完毕,p成为了head且node请求成功了
*/
for (;;) {
final Node p = node.predecessor();//获取插入节点的前一个节点p
/*
* 注意:
* 1、这个是跳出循环的唯一条件,除非抛异常
* 2、如果p == head && tryAcquire(arg)第一次循环就成功了,interrupted为false,不需要中断自己
* 如果p == head && tryAcquire(arg)第一次以后的循环中如果执行了挂起操作后才成功了,interrupted为true,就要中断自己了
*/
if (p == head && tryAcquire(arg)) {
setHead(node);//当前节点设置为头节点
p.next = null; // help GC
failed = false;
return interrupted;//跳出循环
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;//被中断了
}
} finally {
if (failed)
cancelAcquire(node);
}
}
AbstractQueuedSynchronizer:shouldParkAfterFailedAcquire(Node pred, Node node)
/**
* 检测当前节点是否可以被安全的挂起(阻塞)
* @param pred 当前节点的前驱节点
* @param node 当前节点
*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;//获取前驱节点(即当前线程的前一个节点)的等待状态
if (ws == Node.SIGNAL)//如果前驱节点的等待状态是SIGNAL,表示当前节点将来可以被唤醒,那么当前节点就可以安全的挂起了
return true;
/*
* 1)当ws>0(即CANCELLED==1),前驱节点的线程被取消了,我们会将该节点之前的连续几个被取消的前驱节点从队列中剔除,返回false(即不能挂起)
* 2)如果ws<=0&&!=SIGNAL,将当前节点的前驱节点的等待状态设为SIGNAL
*/
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
/*
* node.prev = pred = pred.prev;
* 上边这句代码相当于下边这两句
* pred = pred.prev;
* node.prev = pred;
*/
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* 尝试将当前节点的前驱节点的等待状态设为SIGNAL
* 1/这为什么用CAS,现在已经入队成功了,前驱节点就是pred,除了node外应该没有别的线程在操作这个节点了,那为什么还要用CAS?而不直接赋值呢?
* (解释:因为pred可以自己将自己的状态改为cancel,也就是pred的状态可能同时会有两条线程(pred和node)去操作)
* 2/既然前驱节点已经设为SIGNAL了,为什么最后还要返回false
* (因为CAS可能会失败,这里不管失败与否,都返回false,下一次执行该方法的之后,pred的等待状态就是SIGNAL了)
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);//挂起当前的线程
return Thread.interrupted();//如果当前线程已经被中断了,返回true
}
//如果产生了异常,我们就会执行cancelAcquire(Node node)取消node的获取锁的意图。
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
if (node == null)
return;
node.thread = null;
// Skip cancelled predecessors
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
// predNext is the apparent node to unsplice. CASes below will
// fail if not, in which case, we lost race vs another cancel
// or signal, so no further action is necessary.
Node predNext = pred.next;
// Can use unconditional write instead of CAS here.
// After this atomic step, other Nodes can skip past us.
// Before, we are free of interference from other threads.
node.waitStatus = Node.CANCELLED;
// If we are the tail, remove ourselves.
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
unparkSuccessor(node);
}
node.next = node; // help GC
}
}
以上就是一个线程获取非公平锁的整个过程(lock())。
公平
具体用法与非公平锁一样
如果掌握了非公平锁的流程,那么掌握公平锁的流程会非常简单,只有两点不同(最后会讲)。
简化版的步骤:(公平锁的核心)
获取一次锁数量,
B1、如果锁数量为0,如果当前线程是等待队列中的头节点,基于CAS尝试将state(锁数量)从0设置为1一次,如果设置成功,设置当前线程为独占锁的线程;
B2、如果锁数量不为0或者当前线程不是等待队列中的头节点或者上边的尝试又失败了,查看当前线程是不是已经是独占锁的线程了,如果是,则将当前的锁数量+1;如果不是,则将该线程封装在一个Node内,并加入到等待队列中去。等待被其前一个线程节点唤醒。
ReentrantLock:lock()
/**
*获取一个锁
*三种情况:
*1、如果当下这个锁没有被任何线程(包括当前线程)持有,则立即获取锁,锁数量==1,之后被唤醒再执行相应的业务逻辑
*2、如果当前线程正在持有这个锁,那么锁数量+1,之后被唤醒再执行相应的业务逻辑
*3、如果当下锁被另一个线程所持有,则当前线程处于休眠状态,直到获得锁之后,当前线程被唤醒,锁数量==1,再执行相应的业务逻辑
*/
public void lock() {
sync.lock();//调用FairSync的lock()方法
}
FairSync:lock()
final void lock() {
acquire(1);
}
AbstractQueuedSynchronizer:acquire(int arg)就是非公平锁使用的那个方法
FairSync:tryAcquire(int acquires)
/**
* 获取公平锁的方法
* 1)获取锁数量c
* 1.1)如果c==0,如果当前线程是等待队列中的头节点,使用CAS将state(锁数量)从0设置为1,如果设置成功,当前线程独占锁-->请求成功
* 1.2)如果c!=0,判断当前的线程是不是就是当下独占锁的线程,如果是,就将当前的锁数量状态值+1(这也就是可重入锁的名称的来源)-->请求成功
* 最后,请求失败后,将当前线程链入队尾并挂起,之后等待被唤醒。
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (isFirst(current) && 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;
}
最后,如果请求失败后,将当前线程链入队尾并挂起,之后等待被唤醒,下边的代码与非公平锁一样。
总结:公平锁与非公平锁对比
- FairSync:lock()少了插队部分(即少了CAS尝试将state从0设为1,进而获得锁的过程)
- FairSync:tryAcquire(int acquires)多了需要判断当前线程是否在等待队列首部的逻辑(实际上就是少了再次插队的过程,但是CAS获取还是有的)。
- ReentrantLock是基于AbstractQueuedSynchronizer实现的,AbstractQueuedSynchronizer可以实现独占锁也可以实现共享锁,ReentrantLock只是使用了其中的独占锁模式
- 一定要记住"简化版的步骤",这是整个非公平锁与公平锁的核心
释放锁unlock()
int a = 12;
//注意:通常情况下,这个会设置成一个类变量,比如说Segement中的段锁与copyOnWriteArrayList中的全局锁
final ReentrantLock lock = new ReentrantLock();
lock.lock();//获取锁
try {
a++;//业务逻辑
} catch (Exception e) {
}finally{
lock.unlock();//释放锁
}
步骤:
- 1.获取当前的锁数量,然后用这个锁数量减去解锁的数量(这里为1),最后得出结果c
- 2.判断当前线程是不是独占锁的线程,如果不是,抛出异常
- 3.如果c==0,说明锁被成功释放,将当前的独占线程置为null,锁数量置为0,返回true
- 4.如果c!=0,说明释放锁失败,锁数量置为c,返回false
- 5.如果锁被释放成功的话,唤醒距离头节点最近的一个非取消的节点
/**
* 释放这个锁
*1)如果当前线程持有这个锁,则锁数量被递减
*2)如果递减之后锁数量为0,则锁被释放。
*如果当前线程不持久有这个锁,抛出异常
*/
public void unlock() {
sync.release(1);
}
AbstractQueuedSynchronizer:release(int arg)
/**
* 释放锁(在独占模式下)
*/
public final boolean release(int arg) {
if (tryRelease(arg)) {
//如果成功释放锁
Node h = head;//获取头节点:(注意:这里的头节点就是当前正在释放锁的节点)
if (h != null && h.waitStatus != 0)//头结点存在且等待状态不是取消
unparkSuccessor(h);//唤醒距离头节点最近的一个非取消的节点
return true;
}
return false;
}
Sync:tryRelease(int releases)
/**
* 释放锁
*/
protected final boolean tryRelease(int releases) {
int c = getState() - releases;//获取现在的锁数量-传入的解锁数量(这里为1)
if (Thread.currentThread() != getExclusiveOwnerThread())//当前线程不持有锁
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
//锁被释放
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
AbstractQueuedSynchronizer:unparkSuccessor(Node node)
/**
* 唤醒离头节点node最近的一个非取消的节点
* @param node 头节点
*/
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)//将ws设为0状态(即什么状态都不是)
compareAndSetWaitStatus(node, ws, 0);
/*
* 获取头节点的下一个等待状态不是cancel的节点
*/
Node s = node.next;//头节点的下一个节点
if (s == null || s.waitStatus > 0) {
s = null;
/*
* 注意:从后往前遍历找到离头节点最近的一个非取消的节点,从后往前遍历据说是在入队(enq())的时候,可能nodeX.next==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);//唤醒离头节点最近的一个非取消的节点
}