锁
一、锁的分类
- 可重入锁、不可重入锁
- 乐观锁、悲观锁
- 公平锁、非公平锁
- 互斥锁、共享锁
1.1 可重入锁、不可重入锁
Java中提供的synchronized
,ReentranttLock
,ReentrantReadWriteLock
都是可重入锁
重入:当前线程获取到A锁,在获取之后尝试再次获取A锁是可以直接拿到的,如
synchronized(Test.class) {
//do something
synchronized(Test.class) {
//do something
}
}
此处第一部分业务代码与第二部分业务代码都可以拿到
Test.class
这把锁
不可重入:当前线程获取到A锁,在获取之后尝试再次获取A锁,无法获取到的(造成死锁),因为A锁被当前线程占用着,需要等待自己释放锁再获取锁,如
java.util.concurrent.ThreadPoolExecutor.Worker#tryAcquire
protected boolean tryAcquire(int unused) {
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
1.2 乐观锁、悲观锁
Java中提供的synchronized
,ReentranttLock
,ReentrantReadWriteLock
都是悲观锁
Java中提供的CAS
操作,就是乐观锁的一种实现
悲观锁:获取不到锁资源时,会将当前线程挂起(进入BLOCKED、WAITING),线程挂起会涉及用户态和内核态的切换,而这种切换时比较消耗资源的
- 用户态:JVM可自行执行指令,不需要借助操作系统执行
- 内核态:JVM不可自行执行指令,需要操作系统才可执行
乐观锁:获取不到锁资源,可以再次让CPU调度,重新尝试获取锁资源
Atomic
原子性类中,就是基于CAS
乐观锁实现的
1.3 公平锁、非公平锁
Java中提供的synchronized
只能是非公平锁
Java中提供的ReentranttLock
,ReentrantReadWriteLock
可以实现公平锁和非公平锁
公平锁:线程A获取到锁资源,线程B没有拿到,线程B去排队,线程C来了,锁被A持有,同时线程B在排队,直接排到B的后面,等待B拿到了锁资源或者是B取消后,才可以尝试去竞争锁资源
非公平锁:线程A获取到了锁资源,线程B没有拿到,线程B去排队,线程C来了,先尝试竞争一波
- 拿到锁资源:插队成功
- 未拿到锁资源:依然要排到B的后面,等待B拿到锁资源或者是B取消后,才可以尝试去竞争锁资源
1.4 互斥锁、共享锁
Java中提供的synchronized
、ReentranttLock
是互斥锁
Java中提供的ReentrantReadWriteLock
有互斥锁也有共享锁
互斥锁:同一时间点,只会有一个线程持有当前锁
共享锁:同一时间点,当前锁可以被多个线程共同持有(该锁适用于读操作)
二、深入synchronized
2.1 类锁、对象锁
synchronized的使用一般就是同步方法和同步代码块
synchronized的锁是基于对象实现的
如果使用同步方法
- static:此时使用的是当前类.class作为锁(类锁)
- 非static:此时使用的是当前对象作为锁(对象锁)
public class SynchronizedAbout {
public static void main(String[] args) {
//锁的是当前Test.class
Test.a();
Test test = new Test();
//锁的是new出来的test对象
test.b();
}
}
class Test {
public static synchronized void a() {
System.out.println("method a()");
}
public synchronized void b() {
System.out.println("method b()");
}
}
2.2 synchronized优化
在JDK1.5的时候,Doug Lee推出了ReentrantLock
,lock的性能远高于synchronized
,所以JDK团队就在JDK1.6中,对synchronized做了大量优化
-
锁消除:在synchronized修饰的代码中,如果不存在操作临界资源的情况,会触发锁消除,你即便写了synchronized,他也不会触发
public synchronized void method() { //没有操作临界资源 //此时这个方法的synchronized你可以认为没有 }
-
锁膨胀:如果在一个循环中,频繁的获取和释放锁资源,这样带来的消耗很大,锁膨胀就是将锁的范围扩大,避免频繁的竞争和获取锁资源带来不必要的消耗
public void method() { for(int i=0; i<99999; i++) { synchronized(对象) { //此处频繁获取锁释放锁99999次 } } //这时上面的代码会触发锁膨胀,效果如下: synchronized(对象) { for(int i=0; i<99999; i++) { } } }
-
锁升级:
ReentrantLock
的实现,时先基于乐观锁的CAS尝试获取锁资源,如果拿不到锁资源,才会挂起线程;synchronized
在JDK1.6之前,如果获取不到锁,立即挂起当前线程,所以synchronized性能较差;在JDK1.6之后做了锁升级的优化- 无锁、匿名偏向:当前对象没有作为锁的存在
- 偏向锁:如果当前锁资源,只有一个线程在频繁的获取和释放,那么这个线程过来,只需要判断,当前指向的线程是否是当前线程
- 如果是:直接拿着所资源走
- 如果不是:基于CAS的方式,尝试将偏向锁指向当前线程,如果获取不到,触发锁升级,升级为轻量级锁(偏向锁状态出现了锁竞争的情况)
- 轻量级锁:采用自旋的方式去频繁的以CAS的形式获取锁资源(采用的是自适应自旋锁)
- 如果成功获取到,拿着所资源走
- 如果自旋到了一定次数,没有拿到锁资源,锁升级为重量级锁
- 重量级锁:就是最传统的synchronized方式,拿不到锁资源就挂起当前线程(用户态/内核态—切换)
2.3 synchronized实现原理
synchronized是基于对象实现的
先要对Java中对象在堆内存的存储有一个了解,如图:
展开MarkWord(HotSpot的实现)
MarkWord中标记着四种锁的信息:
- 无锁
- 偏向锁
- 轻量级锁
- 重量级锁
2.4 synchronized的锁升级
为了可以在Java中看到对象头的MarkWord
信息,需要导入依赖
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
锁默认情况下,开启了偏向锁延迟
偏向锁在升级为轻量级锁时,会涉及到偏向锁撤销,需要等到一个安全点(STW),才可以做偏向锁撤销,在明知道有并发情况,就可以选择不开启偏向锁,或者是设置偏向锁延迟开启
因为JVM在启动时,需要加载大量的.class文件到内存中,这个操作会涉及到synchronized的使用,为了避免出现偏向锁撤销操作,JVM启动初期,有一个延迟5s开启偏向锁的操作
如果正常开启了偏向锁,那么不会出现无锁状态,对象会直接变为匿名偏向
public class SynchronizedUpgrade {
public static void main(String[] args) throws InterruptedException {
Object o = new Object();
//匿名偏向锁
System.out.println(ClassLayout.parseInstance(o).toPrintable()); //匿名偏向锁(101,后3字节未指向)
new Thread(() -> {
synchronized (o) {
//t1: 偏向锁(可能)-> 轻量级锁(可能) -> 重量级锁(可能)
System.out.println("t1:" + ClassLayout.parseInstance(o).toPrintable());
}
}).start();
synchronized (o) {
//main: 偏向锁(可能)-> 轻量级锁(可能) -> 重量级锁(可能)
System.out.println("main:" + ClassLayout.parseInstance(o).toPrintable());//偏向锁(101,后3字节有指向)
}
}
}
console
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 00 10 00 00 (00000000 00010000 00000000 00000000) (4096)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
main:java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 05 a8 66 6b (00000101 10101000 01100110 01101011) (1801889797)
4 4 (object header) 0b 02 00 00 (00001011 00000010 00000000 00000000) (523)
8 4 (object header) 00 10 00 00 (00000000 00010000 00000000 00000000) (4096)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
t1:java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 82 32 7b 7f (10000010 00110010 01111011 01111111) (2138780290)
4 4 (object header) 0b 02 00 00 (00001011 00000010 00000000 00000000) (523)
8 4 (object header) 00 10 00 00 (00000000 00010000 00000000 00000000) (4096)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
锁升级的状态的转变:
Lock Record以及ObjectMonitor存储的内容
2.5 重量锁底层ObjectMonitor
需要去找到openjdk,在百度中直接搜索openjdk,第一个链接就是
找到ObjectMonitor的两个文件,hpp,cpp
ObjectMonitor() {
_header = NULL; //header存储着MarkWord
_count = 0; //竞争锁的线程个数
_waiters = 0, //wait的线程个数
_recursions = 0; //标识当前synchronized锁重入的次数
_object = NULL;
_owner = NULL; //持有锁的线程
_WaitSet = NULL; //保存wait的线程信息,双向链表
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; //获取锁资源失败后,线程要放到当前的单向链表中
FreeNext = NULL ;
_EntryList = NULL ; //_cxq以及被唤醒的WaitSet中的线程,在一定机制下,会放到EntryList中
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}
TryLock()
int ObjectMonitor::TryLock (Thread * Self) {
for (;;) {
//拿到持有锁的线程
void * own = _owner ;
//如果有线程持有锁,告辞
if (own != NULL) return 0 ;
//说明没有线程持有锁,own是null,cmpxchg指令就是底层CAS实现
if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
//成功获取锁资源
return 1 ;
}
//这里其实重试操作没什么意义,直接返回-1
if (true) return -1 ;
}
}
try_enter()
bool ObjectMonitor::try_enter(Thread* THREAD) {
//在判断_owner是不是当前线程
if (THREAD != _owner) {
//判断当前持有锁的线程是否是当前线程,说明轻量级锁刚刚升级过来的情况
if (THREAD->is_lock_owned ((address)_owner)) {
_owner = THREAD ;
_recursions = 1 ;
OwnerIsThread = 1 ;
return true;
}
//CAS操作,尝试获取锁资源
if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
//没拿到锁资源,告辞
return false;
}
//拿到锁资源
return true;
} else {
//将_recursions+1,代表锁重入操作
_recursions++;
return true;
}
}
enter():想法设法拿到锁资源,如果没拿到,挂起仍到_cxq
单向链表中
void ATTR ObjectMonitor::enter(TRAPS) {
//拿到当前线程
Thread * const Self = THREAD ;
void * cur ;
//CAS走你,
cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
if (cur == NULL) {
//拿锁成功
return ;
}
//锁重入操作
if (cur == Self) {
// TODO-FIXME: check for integer overflow! BUGID 6557169.
_recursions ++ ;
return ;
}
//轻量级锁过来的
if (Self->is_lock_owned ((address)cur)) {
_recursions = 1 ;
_owner = Self ;
OwnerIsThread = 1 ;
return ;
}
//走到这了,没拿到锁资源,count++
Atomic::inc_ptr(&_count);
for (;;) {
jt->set_suspend_equivalent();
//入队操作,进到cxq中
EnterI (THREAD) ;
if (!ExitSuspendEquivalent(jt)) break ;
_recursions = 0 ;
_succ = NULL ;
exit (false, Self) ;
jt->java_suspend_self();
}
}
//count--
Atomic::dec_ptr(&_count);
}
EnterI()
for (;;) {
//入队
node._next = nxt = _cxq ;
//CAS的方式入队(如果不已CAS方式入队会造成线程安全问题,以CAS入队,如果没成功入队再来一次直到入队成功为止)
if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;
//重新尝试获取锁资源
if (TryLock (Self) > 0) {
assert (_succ != Self , "invariant") ;
assert (_owner == Self , "invariant") ;
assert (_Responsible != Self , "invariant") ;
return ;
}
}
三、深入ReentrantLock
3.1 ReentrantLock与synchronized的区别
核心区别:
- ReentrantLock是个类,synchronized是关键字,当然都是在JVM层面实现互斥锁的方式
效率区别:
- 如果竞争比较激烈,推荐ReentrantLock去实现,不存在锁升级概念。而synchronized是存在锁升级概念的,如果升级到重量级锁,是不存在锁降级的
底层实现区别:
- 实现原理不一样,ReetrantLock基于AQS实现的,synchronized是基于ObjectMonitor
功能项的区别:
- ReentrantLock功能比synchronized更全面
- ReentrantLock支持公平锁和非公平锁
- ReentrantLock可以指定等待锁资源的时间
选择哪个:如果你对并发编程特别熟练,推荐使用ReentrantLock,功能更丰富,如果掌握的一般般,使用synchronized会更好
3.2 AQS概述
AQS就是JUC包下的一个基类:AbstractQueuedSynchronizer
JUC下的很多内容都是基于AQS实现了部分功能,如:ReentrantLock,ThreadPoolExecutor,阻塞队列,CountDownLatch,Semaphore,CyclicBarrier等等都是基于AQS实现
首先AQS中提供了一个由volatile修饰,并且采用CAS方式修饰的int类型的state变量
其次AQS中维护了一个双向链表,由head,由tail,并且每个节点都是Node对象
static final class Node {
static final Node SHARED = new Node();
static final Node EXCLUSIVE = null;
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
volatile int waitStatus;
volatile Node prev;
volatile Node next;
volatile Thread thread;
}
waitStatus与state不同取值含义
waitStatus
- CANCELLED:线程已取消
- SIGNAL:后继线程需要取消停放(挂起)
- CONDITION:线程正在等待条件(放在Condition队列中的节点的waitStatus必然为该值,参见3.6.3)
- PROPAGATE:下一个 acquireShared 应该无条件传播(信号量相关,这里不涉及)
waitStatus是Node节点的状态,默认是0(无后继节点,本身就是最后一个节点),1是取消(大于0都是),-1是后继节点可能挂起记得唤醒。 -2代表在Condition队列,await挂起了。 -3代表传播,在读写锁里基于-3唤醒读锁资源
state
state是AQS的成员变量,锁利用AQS的话,state为0就没线程持有,大于0就是有线程持有且大于1为锁重入次数
AQS内部结构和属性
3.3 加锁流程源码剖析
3.3.1 加锁流程概述
3.3.2 三种加锁源码分析
3.3.2.1 lock方法
-
执行lock方法后,公平锁和非公平锁的执行套路不一样
// 非公平锁 final void lock() { // 上来就先基于CAS的方式,尝试将state从0改为1 if (compareAndSetState(0, 1)) // 获取锁资源成功,会将当前线程设置到exclusiveOwnerThread属性,代表是当前线程持有着锁资源 setExclusiveOwnerThread(Thread.currentThread()); else // 执行acquire,尝试获取锁资源 acquire(1); } // 公平锁 final void lock() { // 执行acquire,尝试获取锁资源 acquire(1); }
-
acquire方法,是公平锁和非公平锁的逻辑一样
public final void acquire(int arg) { // tryAcquire:再次查看,当前线程是否可以尝试获取锁资源 if (!tryAcquire(arg) && // 没有拿到锁资源 // addWaiter(Node.EXCLUSIVE):将当前线程封装为Node节点,插入到AQS的双向链表的结尾 // acquireQueued:查看我是否是第一个排队的节点,如果是可以再次尝试获取锁资源,如果长时间拿不到,挂起线程 // 如果不是第一个排队的额节点,就尝试挂起线程即可 acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) // 中断线程的操作 selfInterrupt(); }
-
tryAcquire方法竞争锁最资源的逻辑,分为公平锁和非公平锁
// 非公平锁实现 final boolean nonfairTryAcquire(int acquires) { // 获取当前线程 final Thread current = Thread.currentThread(); // 获取了state属性 int c = getState(); // 判断state当前是否为0,之前持有锁的线程释放了锁资源 if (c == 0) { // 再次抢一波锁资源 if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); // 拿锁成功返回true return true; } } // 不是0,有线程持有着锁资源,如果是,证明是锁重入操作 else if (current == getExclusiveOwnerThread()) { // 将state + 1 int nextc = c + acquires; if (nextc < 0) // 说明对重入次数+1后,超过了int正数的取值范围 // 01111111 11111111 11111111 11111111 // 10000000 00000000 00000000 00000000 // 说明重入的次数超过界限了。 throw new Error("Maximum lock count exceeded"); // 正常的将计算结果,复制给state setState(nextc); // 锁重入成功 return true; } // 返回false return false; } // 公平锁实现 protected final boolean tryAcquire(int acquires) { // 获取当前线程 final Thread current = Thread.currentThread(); // .... int c = getState(); if (c == 0) { // 查看AQS中是否有排队的Node // 没人排队抢一手 。有人排队,如果我是第一个,也抢一手 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; } // 查看是否有线程在AQS的双向队列中排队 // 返回false,代表没人排队 public final boolean hasQueuedPredecessors() { // 头尾节点 Node t = tail; Node h = head; // s为头结点的next节点 Node s; // 如果头尾节点相等,证明没有线程排队,直接去抢占锁资源 return h != t && // s节点不为null,并且s节点的线程为当前线程(排在第一名的是不是我) (s == null || s.thread != Thread.currentThread()); }
-
addWaite方法,将没有拿到锁资源的线程扔到AQS队列中去排队
// 没有拿到锁资源,过来排队, mode:代表互斥锁 private Node addWaiter(Node mode) { // 将当前线程封装为Node, Node node = new Node(Thread.currentThread(), mode); // 拿到尾结点 Node pred = tail; // 如果尾结点不为null if (pred != null) { // 当前节点的prev指向尾结点 node.prev = pred; // 以CAS的方式,将当前线程设置为tail节点 if (compareAndSetTail(pred, node)) { // 将之前的尾结点的next指向当前节点 pred.next = node; return node; } } // 如果CAS失败,以死循环的方式,保证当前线程的Node一定可以放到AQS队列的末尾 enq(node); return node; } private Node enq(final Node node) { for (;;) { // 拿到尾结点 Node t = tail; // 如果尾结点为空,AQS中一个节点都没有,构建一个伪节点,作为head和tail if (t == null) { if (compareAndSetHead(new Node())) tail = head; } else { // 比较熟悉了,以CAS的方式,在AQS中有节点后,插入到AQS队列的末尾 node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }
-
acquireQueued方法,判断当前线程是否还能再次尝试获取锁资源,如果不能再次获取锁资源,或者又没获取到,尝试将当前线程挂起
// 当前没有拿到锁资源后,并且到AQS排队了之后触发的方法。 中断操作这里不用考虑 final boolean acquireQueued(final Node node, int arg) { // 不考虑中断 // failed:获取锁资源是否失败(这里简单掌握逻辑,真正触发的,还是tryLock和lockInterruptibly) boolean failed = true; try { boolean interrupted = false; // 死循环………… for (;;) { // 拿到当前节点的前继节点 final Node p = node.predecessor(); // 前继节点是否是head,如果是head,再次执行tryAcquire尝试获取锁资源。 if (p == head && tryAcquire(arg)) { // 获取锁资源成功 // 设置头结点为当前获取锁资源成功Node,并且取消thread信息 setHead(node); // help GC p.next = null; // 获取锁失败标识为false failed = false; return interrupted; } // 没拿到锁资源…… // shouldParkAfterFailedAcquire:基于上一个节点转改来判断当前节点是否能够挂起线程,如果可以返回true, // 如果不能,就返回false,继续下次循环 if (shouldParkAfterFailedAcquire(p, node) && // 这里基于Unsafe类的park方法,将当前线程挂起 parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) // 在lock方法中,基本不会执行。 cancelAcquire(node); } } // 获取锁资源成功后,先执行setHead private void setHead(Node node) { // 当前节点作为头结点 伪 head = node; // 头结点不需要线程信息 node.thread = null; node.prev = null; } // 当前Node没有拿到锁资源,或者没有资格竞争锁资源,看一下能否挂起当前线程 private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { // -1,SIGNAL状态:代表当前节点的后继节点,可以挂起线程,后续我会唤醒我的后继节点 // 1,CANCELLED状态:代表当前节点以及取消了 int ws = pred.waitStatus; if (ws == Node.SIGNAL) // 上一个节点为-1之后,当前节点才可以安心的挂起线程 return true; if (ws > 0) { // 如果当前节点的上一个节点是取消状态,我需要往前找到一个状态不为1的Node,作为他的next节点 // 找到状态不为1的节点后,设置一下next和prev do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { // 上一个节点的状态不是1或者-1,那就代表节点状态正常,将上一个节点的状态改为-1 compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false; }
3.3.2.2 tryLock方法
-
tryLock();
// tryLock方法,无论公平锁还有非公平锁。都会走非公平锁抢占锁资源的操作 // 就是拿到state的值, 如果是0,直接CAS浅尝一下 // state 不是0,那就看下是不是锁重入操作 // 如果没抢到,或者不是锁重入操作,告辞,返回false public boolean tryLock() { // 非公平锁的竞争锁操作 return sync.nonfairTryAcquire(1); } 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; }
-
tryLock(time, unit);
-
先分析类似的代码
// tryLock(time,unit)执行的方法 public final boolean tryAcquireNanos(int arg, long nanosTimeout)throws InterruptedException { // 线程的中断标记位,是不是从false,别改为了true,如果是,直接抛异常 if (Thread.interrupted()) throw new InterruptedException(); // tryAcquire分为公平和非公平锁两种执行方式,如果拿锁成功, 直接告辞, return tryAcquire(arg) || // 如果拿锁失败,在这要等待指定时间 doAcquireNanos(arg, nanosTimeout); } private boolean doAcquireNanos(int arg, long nanosTimeout) throws InterruptedException { // 如果等待时间是0秒,直接告辞,拿锁失败 if (nanosTimeout <= 0L) return false; // 设置结束时间。 final long deadline = System.nanoTime() + nanosTimeout; // 先扔到AQS队列 final Node node = addWaiter(Node.EXCLUSIVE); // 拿锁失败,默认true boolean failed = true; try { for (;;) { // 如果在AQS中,当前node是head的next,直接抢锁 final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return true; } // 结算剩余的可用时间 nanosTimeout = deadline - System.nanoTime(); // 判断是否是否用尽的位置 if (nanosTimeout <= 0L) return false; // shouldParkAfterFailedAcquire:根据上一个节点来确定现在是否可以挂起线程 if (shouldParkAfterFailedAcquire(p, node) && // 避免剩余时间太少,如果剩余时间少就不用挂起线程 nanosTimeout > spinForTimeoutThreshold) // 如果剩余时间足够,将线程挂起剩余时间 LockSupport.parkNanos(this, nanosTimeout); // 如果线程醒了,查看是中断唤醒的,还是时间到了唤醒的。 if (Thread.interrupted()) // 是中断唤醒的! throw new InterruptedException(); } } finally { if (failed) cancelAcquire(node); } }
-
取消节点分析:
// 取消在AQS中排队的Node private void cancelAcquire(Node node) { // 如果当前节点为null,直接忽略。 if (node == null) return; //1. 线程设置为null node.thread = null; //2. 往前跳过被取消的节点,找到一个有效节点 Node pred = node.prev; while (pred.waitStatus > 0) node.prev = pred = pred.prev; //3. 拿到了上一个节点之前的next Node predNext = pred.next; //4. 当前节点状态设置为1,代表节点取消 node.waitStatus = Node.CANCELLED; // 脱离AQS队列的操作 // 当前Node是尾结点,将tail从当前节点替换为上一个节点 if (node == tail && compareAndSetTail(node, pred)) { compareAndSetNext(pred, predNext, null); } else { // 到这,上面的操作CAS操作失败 int ws = pred.waitStatus; // 不是head的后继节点 if (pred != head && // 拿到上一个节点的状态,只要上一个节点的状态不是取消状态,就改为-1 (ws == 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 { // 当前节点是head的后继节点 unparkSuccessor(node); } node.next = node; // help GC } }
-
3.3.2.3 lockInterruptibly方法
// 这个是lockInterruptibly和tryLock(time,unit)唯一的区别
// lockInterruptibly,拿不到锁资源,就死等,等到锁资源释放后,被唤醒,或者是被中断唤醒
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())
// 中断唤醒抛异常!
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
// 这个方法可以确认,当前挂起的线程,是被中断唤醒的,还是被正常唤醒的。
// 中断唤醒,返回true,如果是正常唤醒,返回false
return Thread.interrupted();
}
3.4 释放锁流程源码剖析
3.4.1 释放锁流程概述
3.4.2 释放锁源码分析
public void unlock() {
// 释放锁资源不分为公平锁和非公平锁,都是一个sync对象
sync.release(1);
}
// 释放锁的核心流程
public final boolean release(int arg) {
// 核心释放锁资源的操作之一
if (tryRelease(arg)) {
// 如果锁已经释放掉了,走这个逻辑
Node h = head;
// h不为null,说明有排队的
// 如果h的状态不为0(为-1),说明后面有排队的Node,并且线程已经挂起了。
if (h != null && h.waitStatus != 0)
// 唤醒排队的线程
unparkSuccessor(h);
return true;
}
return false;
}
// ReentrantLock释放锁资源操作
protected final boolean tryRelease(int releases) {
// 拿到state - 1(并没有赋值给state)
int c = getState() - releases;
// 判断当前持有锁的线程是否是当前线程,如果不是,直接抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
// free,代表当前锁资源是否释放干净了。
boolean free = false;
if (c == 0) {
// 如果state - 1后的值为0,代表释放干净了。
free = true;
// 将持有锁的线程置位null
setExclusiveOwnerThread(null);
}
// 将c设置给state
setState(c);
// 锁资源释放干净返回true,否则返回false
return free;
}
// 唤醒后面排队的Node
private void unparkSuccessor(Node node) {
// 拿到头节点状态
int ws = node.waitStatus;
if (ws < 0)
// 先基于CAS,将节点状态从-1,改为0
compareAndSetWaitStatus(node, ws, 0);
// 拿到头节点的后续节点。
Node s = node.next;
// 如果后续节点为null或者,后续节点的状态为1,代表节点取消了。
if (s == null || s.waitStatus > 0) {
s = null;
// 如果后续节点为null,或者后续节点状态为取消状态,从后往前找到一个有效节点环境
for (Node t = tail; t != null && t != node; t = t.prev)
// 从后往前找到状态小于等于0的节点
// 找到离head最新的有效节点,并赋值给s
if (t.waitStatus <= 0)
s = t;
}
// 只要找到了这个需要被唤醒的节点,执行unpark唤醒
if (s != null)
LockSupport.unpark(s.thread);
}
3.5 AQS中常见的问题
3.5.1 AQS为什么要有一个虚拟的head节点
AQS可以没有head,设计之初指定head只是为了更方便的操作。方便管理双向链表而已,作为哨兵节点的存在
比如ReentrantLock
中释放锁资源时,会考虑是否需要唤醒后继节点。如果头结点的状态不是-1。就不需要去唤醒后继节点。唤醒后继节点时,需要找到head.next
节点,如果head.next
为null
,或者是取消了,此时需要遍历整个双向链表,从后往前遍历,找到离head
最近的Node
。规避了一些不必要的唤醒操作。
如果不用虚拟节点(哨兵节点),当前节点挂起,当前节点的状态设置为-1,可行。但AQS本身就是使用了哨兵节点做双向链表的一些操作。
网上说了,虚拟的head,可以避免重复唤醒操作。虚拟的head并没有处理这个问题
3.5.2 AQS中为什么使用双向链表
AQS的双向链表就是为了更方便的操作Node节点
在执行tryLock
,lockInterruptibly
方法时,如果在线程阻塞时,中断了线程,此时线程会执行cancelAcquire
取消当前节点,不在AQS的双向链表中排队。如果是单向链表,此时会导致取消节点,无法直接将当前节点的prev
节点的next
指针,指向但钱节点的next
节点
3.6 ConditionObject
3.6.1 ConditionObject的介绍&应用
像synchronized提供了wait和notify的方法实现线程在持有锁时,可以实现挂起,已经唤醒的操作
ReentrantLock也拥有这个功能
ReentrantLock提供了await和signal方法去实现类似wait和notify的功能
想执行await或者是signal就必须先持有lock锁的资源
Condition的应用
public static void main(String[] args) throws InterruptedException {
ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
new Thread(() -> {
lock.lock();
System.out.println("子线程获取锁资源并await挂起线程");
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
try {
condition.await();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
System.out.println("子线程挂起后被唤醒!持有锁资源");
}).start();
Thread.sleep(100); //防止主线程先被执行
//------------------main-----------------
lock.lock();
System.out.println("主线程等待5s拿到锁资源,子线程执行了await方法");
//唤醒子线程,并到AQS队列中排队
condition.signal();
System.out.println("主线程唤醒了await挂起的子线程");
//释放锁资源,AQS队列中的子线程得以拿到锁资源继续执行
lock.unlock();
}
执行结果
子线程获取锁资源并await挂起线程
主线程等待5s拿到锁资源,子线程执行了await方法
主线程唤醒了await挂起的子线程
子线程挂起后被唤醒!持有锁资源
Process finished with exit code 0
3.6.2 Condition的构建方式&核心属性
发现在通过lock
锁对象执行newCondition
方法时,本质就是直接new的AQS提供的ConditionObject
对象
final ConditionObject newCondition() {
return new ConditionObject();
}
其实lock
锁中可以有多个Condition
对象
在对Condition1
进行操作时,不会影响到Condition2
的单向链表
其次可以发现ConditionObject
中,只有两个核心属性:
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;
虽然Node
对象有prev
和next
,但是在ConditionObject
中是不会使用这两个属性的,只要在Condition
队列中,这两个属性都是null
。在ConditionObject
中只会使用nextWaiter
的属性实现单向链表的效果
3.6.3 Condition的await方法分析(前置分析)
持有锁的线程在执行await
方法后会做几个操作:
- 判断线程是否中断,如果中断了,什么都不做
- 没有中断,就将当前线程封装为
Node
添加到Condition
的单向链表中 - 一次性释放掉锁资源
- 如果当前线程没有在AQS队列,就正常执行
LockSupport.park(this)
挂起线程
// await方法的前置分析,只分析到线程挂起
public final void await() throws InterruptedException {
// 先判断线程的中断标记位是否是true
if (Thread.interrupted())
// 如果是true,就没必要执行后续操作挂起了。
throw new InterruptedException();
// 在线程挂起之前,先将当前线程封装为Node,并且添加到Condition队列中
Node node = addConditionWaiter();
// fullyRelease在释放锁资源,一次性将锁资源全部释放,并且保留重入的次数
int savedState = fullyRelease(node);
// 省略一行代码……
// 当前Node是否在AQS队列中?
// 执行fullyRelease方法后,线程就释放锁资源了,如果线程刚刚释放锁资源,其他线程就立即执行了signal方法,
// 此时当前线程就被放到了AQS的队列中,这样一来线程就不需要执行LockSupport.park(this);去挂起线程了
while (!isOnSyncQueue(node)) {
// 如果没有在AQS队列中,正常在Condition单向链表里,正常挂起线程。
LockSupport.park(this);
// 省略部分代码……
}
// 省略部分代码……
}
// 线程挂起先,添加到Condition单向链表的业务~~
private Node addConditionWaiter() {
// 拿到尾节点。
Node t = lastWaiter;
// 如果尾节点有值,并且尾节点的状态不正常,不是-2,尾节点可能要拜拜了~
if (t != null && t.waitStatus != Node.CONDITION) {
// 如果尾节点已经取消了,需要干掉取消的尾节点~
unlinkCancelledWaiters();
// 重新获取lastWaiter
t = lastWaiter;
}
// 构建当前线程的Node,并且状态设置为-2
Node node = new Node(Thread.currentThread(), Node.CONDITION);
// 如果last节点为null。直接将当前节点设置为firstWaiter
if (t == null)
firstWaiter = node;
else
// 如果last节点不为null,说明有值,就排在lastWaiter的后面
t.nextWaiter = node;
// 把当前节点设置为最后一个节点
lastWaiter = node;
// 返回当前节点
return node;
}
// 干掉取消的尾节点。
private void unlinkCancelledWaiters() {
// 拿到头节点
Node t = firstWaiter;
// 声明一个节点,爱啥啥~~~
Node trail = null;
// 如果t不为null,就正常执行~~
while (t != null) {
// 拿到t的next节点
Node next = t.nextWaiter;
// 如果t的状态不为-2,说明有问题
if (t.waitStatus != Node.CONDITION) {
// t节点的next为null
t.nextWaiter = null;
// 如果trail为null,代表头结点状态就是1,
if (trail == null)
// 将头结点指向next节点
firstWaiter = next;
else
// 如果trail有值,说明不是头结点位置
trail.nextWaiter = next;
// 如果next为null,说明单向链表遍历到最后了,直接结束
if (next == null)
lastWaiter = trail;
}
// 如果t的状态是-2,一切正常
else {
// 临时存储t
trail = t;
}
// t指向之前的next
t = next;
}
}
// 一次性释放锁资源
final int fullyRelease(Node node) {
// 标记位,释放锁资源默认失败!
boolean failed = true;
try {
// 拿到现在state的值(锁的重入次数)
int savedState = getState();
// 一次性释放干净全部锁资源
if (release(savedState)) {
// 释放锁资源失败了么? 没有!
failed = false;
// 返回对应的锁资源信息
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
// 如果释放锁资源失败,将节点状态设置为取消
node.waitStatus = Node.CANCELLED;
}
}
3.6.4 Condition的signal方法分析
分为了几个部分:
- 确保执行
signal
方法的是持有锁的线程 - 脱离
Condition
的队列 - 将
Node
状态从-2
改为0
- 将
Node
添加到AQS队列 - 为了避免当前
Node
无法在AQS队列正常唤醒做了一些判断和操作
// 线程挂起后,可以基于signal唤醒~
public final void signal() {
// 在ReentrantLock中,如果执行signal的线程没有持有锁资源,直接扔异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 拿到排在Condition首位的Node
Node first = firstWaiter;
// 有Node在排队,才需要唤醒,如果没有,直接告辞~~
if (first != null)
doSignal(first);
}
// 开始唤醒Condition中的Node中的线程
private void doSignal(Node first) {
// 先一波do-while走你~~~
do {
// 获取到第二个节点,并且将第二个节点设置为firstWaiter
if ( (firstWaiter = first.nextWaiter) == null)
// 说明就一个节点在Condition队列中,那么直接将firstWaiter和lastWaiter置位null
lastWaiter = null;
// 如果还有nextWaiter节点,因为当前节点要被唤醒了,脱离整个Condition队列。将nextWaiter置位null
first.nextWaiter = null;
// 如果transferForSignal返回true,一切正常,退出while循环
} while (!transferForSignal(first) &&
// 如果后续节点还有,往后面继续唤醒,如果没有,退出while循环
(first = firstWaiter) != null);
}
// 准备开始唤醒在Condition中排队的Node
final boolean transferForSignal(Node node) {
// 将在Condition队列中的Node的状态从-2,改为0,代表要扔到AQS队列了。
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
// 如果失败了,说明在signal之前应当是线程被中断了,从而被唤醒了。
return false;
// 如果正常的将Node的状态从-2改为0,这是就要将Condition中的这个Node扔到AQS的队列。
// 将当前Node扔到AQS队列,返回的p是当前Node的prev
Node p = enq(node);
// 获取上一个Node的状态
int ws = p.waitStatus;
// 如果ws > 0 ,说明这个Node已经被取消了。
// 如果ws状态不是取消,将prev节点的状态改为-1,。
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
// 如果prev节点已经取消了,可能会导致当前节点永远无法被唤醒。立即唤醒当前节点,基于acquireQueued方法,
// 让当前节点找到一个正常的prev节点,并挂起线程
// 如果prev节点正常,但是CAS修改prev节点失败了。证明prev节点因为并发原因导致状态改变。还是为了避免当前
// 节点无法被正常唤醒,提前唤醒当前线程,基于acquireQueued方法,让当前节点找到一个正常的prev节点,并挂起线程
LockSupport.unpark(node.thread);
// 返回true
return true;
}
3.6.5 Conditiond的await方法分析(后置分析)
分为了几个部分:
- 唤醒之后,要先确认是
中断唤醒
还是signal唤醒
,还是signal唤醒后被中断
- 确保当前线程的
Node
已经在AQS队列中 - 执行
acquireQueued
方法,等待锁资源 - 在获取锁资源后,要确认是否在获取锁资源的阶段被中断过,如果被中断过,并且不是
THROW_IE
,那就确保interruptMode
是REINTERRUPT
- 确认当前
Node
已经不在Condition
队列中了 - 最终根据
interruptMode
来决定具体做的事情- 0:什么也不做。
- THROW_IE:抛出异常
- REINTERRUPT:执行线程的
interrupt
方法,确保线程的中断标记位
// 现在分析await方法的后半部分
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
// 中断模式~
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
// 如果线程执行到这,说明现在被唤醒了。
// 线程可以被signal唤醒。(如果是signal唤醒,可以确认线程已经在AQS队列中)
// 线程可以被interrupt唤醒,线程被唤醒后,没有在AQS队列中。
// 如果线程先被signal唤醒,然后线程中断了。。。。(做一些额外处理)
// checkInterruptWhileWaiting可以确认当前是如何唤醒的。
// 返回的值,有三种
// 0:正常signal唤醒,没别的事(不知道Node是否在AQS队列)
// THROW_IE(-1):中断唤醒,并且可以确保在AQS队列
// REINTERRUPT(1):signal唤醒,但是线程被中断了,并且可以确保在AQS队列
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// Node一定在AQS队列
// 执行acquireQueued,尝试在ReentrantLock中获取锁资源。
// acquireQueued方法返回true:代表线程在AQS队列中挂起时,被中断过
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
// 如果线程在AQS队列排队时,被中断了,并且不是THROW_IE状态,确保线程的interruptMode是REINTERRUPT
// REINTERRUPT:await不是中断唤醒,但是后续被中断过!!!
interruptMode = REINTERRUPT;
// 如果当前Node还在condition的单向链表中,脱离Condition的单向链表
if (node.nextWaiter != null)
unlinkCancelledWaiters();
// 如果interruptMode是0,说明线程在signal后以及持有锁的过程中,没被中断过,什么事都不做!
if (interruptMode != 0)
// 如果不是0~
reportInterruptAfterWait(interruptMode);
}
// 判断当前线程被唤醒的模式,确认interruptMode的值。
private int checkInterruptWhileWaiting(Node node) {
// 判断线程是否中断了。
return Thread.interrupted() ?
// THROW_IE:代表线程是被interrupt唤醒的,需要向上排除异常
// REINTERRUPT:代表线程是signal唤醒的,但是在唤醒之后,被中断了。
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
// 线程是正常的被signal唤醒,并且线程没有中断过。
0;
}
// 判断线程到底是中断唤醒的,还是signal唤醒的!
final boolean transferAfterCancelledWait(Node node) {
// 基于CAS将Node的状态从-2改为0
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
// 说明是中断唤醒的线程。因为CAS成功了。
// 将Node添加到AQS队列中~(如果是中断唤醒的,当前线程同时存在Condition的单向链表以及AQS的队列中)
enq(node);
// 返回true
return true;
}
// 判断当前的Node是否在AQS队列(signal唤醒的,但是可能线程还没放到AQS队列)
// 等到signal方法将线程的Node扔到AQS队列后,再做后续操作
while (!isOnSyncQueue(node))
// 如果没在AQS队列上,那就线程让步,稍等一会,Node放到AQS队列再处理(看CPU)
Thread.yield();
// signal唤醒的,返回false
return false;
}
// 确认Node是否在AQS队列上
final boolean isOnSyncQueue(Node node) {
// 如果线程状态为-2,肯定没在AQS队列
// 如果prev节点的值为null,肯定没在AQS队列
if (node.waitStatus == Node.CONDITION || node.prev == null)
// 返回false
return false;
// 如果节点的next不为null。说明已经在AQS队列上。、
if (node.next != null)
// 确定AQS队列上有!
return true;
// 如果上述判断都没有确认节点在AQS队列上,在AQS队列中寻找一波
return findNodeFromTail(node);
}
// 在AQS队列中找当前节点
private boolean findNodeFromTail(Node node) {
// 拿到尾节点
Node t = tail;
for (;;) {
// tail是否是当前节点,如果是,说明在AQS队列
if (t == node)
// 可以跳出while循环
return true;
// 如果节点为null,AQS队列中没有当前节点
if (t == null)
// 进入while,让步一手
return false;
// t向前引用
t = t.prev;
}
}
private void reportInterruptAfterWait(int interruptMode) throws InterruptedException {
// 如果是中断唤醒的await,直接抛出异常!
if (interruptMode == THROW_IE)
throw new InterruptedException();
// 如果是REINTERRUPT,signal后被中断过
else if (interruptMode == REINTERRUPT)
// 确认线程的中断标记位是true
// Thread.currentThread().interrupt();
selfInterrupt();
}
3.6.6 Condition的awaitNanos&signalAll方法分析
awaitNanos
仅仅是在await方法的基础上,做了一内内的改变,整体的逻辑思想都是一样的。
挂起线程时,传入要阻塞的时间,时间到了,自动唤醒,走添加到AQS队列的逻辑
// await指定时间,多了个时间到了自动醒。
public final long awaitNanos(long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
// deadline:当前线程最多挂起到什么时间点
final long deadline = System.nanoTime() + nanosTimeout;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
// nanosTimeout的时间小于等于0,直接告辞!!
if (nanosTimeout <= 0L) {
// 正常扔到AQS队列
transferAfterCancelledWait(node);
break;
}
// nanosTimeout的时间大于1000纳秒时,才可以挂起线程
if (nanosTimeout >= spinForTimeoutThreshold)
// 如果大于,正常挂起
LockSupport.parkNanos(this, nanosTimeout);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
// 计算剩余的挂起时间,可能需要重新的走while循环,再次挂起线程
nanosTimeout = deadline - System.nanoTime();
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
// 剩余的挂起时间
return deadline - System.nanoTime();
}
signalAll
这个方法一看就懂,之前signal是唤醒1个,这个是全部唤醒
public final void signalAll() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
// 以do-while的形式,将Condition单向链表中的所有Node,全部唤醒并扔到AQS队列
private void doSignalAll(Node first) {
// 将头尾都置位null~
lastWaiter = firstWaiter = null;
do {
// 拿到next节点的引用
Node next = first.nextWaiter;
// 断开当前Node的nextWaiter
first.nextWaiter = null;
// 修改Node状态,扔AQS队列,是否唤醒!
transferForSignal(first);
// 指向下一个节点
first = next;
} while (first != null);
}
四、深入ReentrantReadWriteLock
4.1 为什么要出现读写锁
synchronized
和ReentrantLock
都是互斥锁
如果说有一个操作是读多写少的,还要保证线程安全的话。如果采用上述的两种互斥锁,效率方面很定是很低的
在这种情况下,就可以使用ReentrantReadWriteLock
读写锁去实现
读读之间是不互斥的,可以读和读操作并发执行
但是如果涉及到了写操作(有读有写或者都是写操作),那么还得是互斥的操作
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
//读锁
static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
//写锁
static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
readLock.lock();
try {
System.out.println("child1 thread!");
Thread.sleep(5000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}finally {
readLock.unlock();
}
}).start();
Thread.sleep(100); //保证子线程先执行
writeLock.lock();
try {
System.out.println("main thread!");
} finally {
writeLock.unlock();
}
}
案例分析
都是readLock:子线程和主线程基本上会同时打印
都是writeLock:互斥访问,待子线程释放锁后主线程才会拿到锁继续执行
readLock与writeLock并存:互斥访问,本质上获取的都是同一把lock锁,先要待子线程释放读锁后写锁才能拿到锁资源继续执行
连续多个线程使用readLock可并发执行,直到遇见writeLock进行互斥访问(可见
写锁的饥饿问题
)
4.2 读写锁原理的实现原理
ReentrantReadWriteLock还是基于AQS实现的,还是对state进行操作,拿到锁资源就去干活,如果没有拿到,依然去AQS队列中排队
读锁操作:基于state的高16位进行操作
写锁操作:基于state的低16为进行操作
ReentrantReadWriteLock依然是可重入锁
写锁重入:读写锁中的写锁的重入方式,基本和ReentrantLock
一致,没有什么区别,依然是对state
进行+1
操作即可,只要确认持有锁资源的线程,是当前写锁线程即可。只不过之前ReentrantLock
的重入次数是state
的正数取值范围,但是读写锁中写锁范围就变小了
读锁重入:因为读锁是共享锁
。读锁在获取锁资源操作时,是要对state
的高16位进行 + 1
操作。因为读锁是共享锁,所以同一时间会有多个读线程持有读锁资源。这样一来,多个读操作在持有读锁时,无法确认每个线程读锁重入的次数。为了去记录读锁重入的次数,每个读操作的线程,都会有一个ThreadLocal
记录锁重入的次数
写锁的饥饿问题:读锁是共享锁,当有线程持有读锁资源时,再来一个线程想要获取读锁,直接对state
修改即可。在读锁资源先被占用后,来了一个写锁资源,此时,大量的需要获取读锁的线程来请求锁资源,如果可以绕过写锁,直接拿资源,会造成写锁长时间无法获取到写锁资源
解决写锁的饥饿问题
读锁在拿到锁资源后,如果再有读线程需要获取读锁资源,需要去AQS队列排队。如果队列的前面有需要写锁资源的线程,那么后续读线程是无法拿到锁资源的。持有读锁的线程,只会让写锁线程之前的读线程拿到锁资源
4.3 写锁分析
4.3.1 写锁加锁流程概述
4.3.2 写锁加锁源码分析
写锁加锁流程
// 写锁加锁的入口
public void lock() {
sync.acquire(1);
}
// 阿巴阿巴!!
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
// 读写锁的写锁实现tryAcquire
protected final boolean tryAcquire(int acquires) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到state的值
int c = getState();
// 得到state低16位的值
int w = exclusiveCount(c);
// 判断是否有线程持有着锁资源
if (c != 0) {
// 当前没有线程持有写锁,读写互斥(判断state低16位是否等于0【未获取到锁】),告辞
// 有线程持有写锁,持有写锁的线程不是当前线程,不是锁重入,告辞
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 当前线程持有写锁。 锁重入。
if (w + exclusiveCount(acquires) > MAX_COUNT)
// 当前线程锁重入次数+1 > 最大低16位表示数值抛出异常
throw new Error("Maximum lock count exceeded");
// 没有超过锁重入的次数,正常 + 1
setState(c + acquires);
return true;
}
// 尝试获取锁资源
if (writerShouldBlock() ||
// CAS拿锁
!compareAndSetState(c, c + acquires))
return false;
// 拿锁成功,设置占有互斥锁的线程
setExclusiveOwnerThread(current);
// 返回true
return true;
}
// 公平锁
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
// 写锁
final boolean writerShouldBlock() {
// 与ReentrantLock公平锁一致
return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
}
// 非公平锁
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
//写锁
final boolean writerShouldBlock() {
return false; // 返回false
}
final boolean readerShouldBlock() {
return apparentlyFirstQueuedIsExclusive();
}
}
// ================================================================
// 这个方法是将state的低16位的值拿到
int w = exclusiveCount(c);
state & ((1 << 16) - 1)
00000000 00000000 00000000 00000001 == 1
00000000 00000001 00000000 00000000 == 1 << 16
00000000 00000000 11111111 11111111 == (1 << 16) - 1
&运算,一个为0,必然为0,都为1,才为1
// ================================================================
// writerShouldBlock方法查看公平锁和非公平锁的效果
// 非公平锁直接返回false执行CAS尝试获取锁资源
// 公平锁需要查看是否有排队的,如果有排队的,我是否是head的next
4.3.3 写锁释放锁流程概述&释放锁源码
释放的流程和ReentrantLock一致,只是在判断释放是否干净时,判断低16位的值
// 写锁释放锁的tryRelease方法
protected final boolean tryRelease(int releases) {
// 判断当前持有写锁的线程是否是当前线程
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 获取state - 1
int nextc = getState() - releases;
// 判断低16位结果是否为0,如果为0,free设置为true
boolean free = exclusiveCount(nextc) == 0;
if (free)
// 将持有锁的线程设置为null
setExclusiveOwnerThread(null);
// 设置给state
setState(nextc);
// 释放干净,返回true。 写锁有重入,这里需要返回false,不去释放排队的Node
return free;
}
4.4 读锁分析
- 分析读锁加速的基本流程
- 分析读锁的可重入锁实现以及优化
- 解决
ThreadLocal
内存泄漏问题 - 读锁获取锁自后,如果唤醒AQS中排队的读线程
4.4.1 基础读锁流程
针对上述简单逻辑的源码分析
// 读锁加锁的方法入口
public final void acquireShared(int arg) {
// 竞争锁资源滴干活
if (tryAcquireShared(arg) < 0)
// 没拿到锁资源,去排队
doAcquireShared(arg);
}
// 读锁竞争锁资源的操作
protected final int tryAcquireShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到state
int c = getState();
// 拿到state的低16位,判断 != 0,有写锁占用着锁资源
// 并且,当前占用锁资源的线程不是当前线程
if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
// 写锁被其他线程占用,无法获取读锁,直接返回 -1,去排队
return -1;
// 没有线程持有写锁或者当前线程持有写锁
// 获取读锁的信息,state的高16位。
int r = sharedCount(c);
// 公平锁:查看队列是否有排队的,有排队的,直接告辞,进不去if,后面也不用判断(没人排队继续走)
// 非公平锁:没有排队的,直接抢。 有排队的,但是读锁其实不需要排队,如果出现这个情况,大部分是写锁资源刚刚释放,
// 后续Node还没有来得及拿到读锁资源,当前竞争的读线程,可以直接获取
if (!readerShouldBlock() &&
// 判断持有读锁的临界值是否达到
r < MAX_COUNT &&
// CAS修改state,对高16位进行 + 1
compareAndSetState(c, c + SHARED_UNIT)) {
// 省略部分代码!!!! 【参见4.4.3】
return 1;
}
return fullTryAcquireShared(current);
}
// readerShouldBlock非公平锁的判断
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null && // head为null,可以直接抢占锁资源
(s = h.next) != null && // head的next为null,可以直接抢占锁资源
!s.isShared() && // 如果排在head后面的Node,是共享锁,可以直接抢占锁资源。
s.thread != null; // 后面排队的thread为null,可以直接抢占锁资源
}
4.4.2 读锁重入流程
重入操作
前面阐述过,读锁为了记录锁重入的次数,需要让每个读线程用ThreadLocal
存储重入次数
ReentrantReadWriteLock
对读锁重入做了一些优化操作(涉及参数均在ReentrantReadWriteLock
内部类Sync
)
记录重入次数的核心
ReentrantReadWriteLock
在内部对ThreadLocal做了封装,基于HoldCount
的对象存储重入次数,在内部有个count
属性记录,而且每个线程都是自己的ThreadLocalHoldCounter
,所以可以直接对内部的count
进行++操作。
第一个获取读锁资源的重入次数记录方式
第一个拿到读锁资源的线程,不需要通过ThreadLocal
存储,内部提供了两个属性来记录第一个拿到读锁资源线程的信息
内部提供了firstReader
记录第一个拿到读锁资源的线程,firstReaderHoldCount
记录firstReader
的锁重入次数
最后一个获取读锁资源的重入次数记录方式
最后一个拿到读锁资源的线程,也会缓存他的重入次数,这样++起来更方便
基于cachedHoldCounter
缓存最后一个拿到锁资源现成的重入次数
最后一个获取读锁资源的重入次数记录方式
重入次数的流程执行方式
- 判断当前线程是否是第一个拿到读锁资源的:如果是,直接将
firstReader
以及firstReaderHoldCount
设置为当前线程的信息 - 判断当前线程是否是
firstReader
:如果是,直接对firstReaderHoldCount++
即可 - 跟
firstReader
没关系了,先获取cachedHoldCounter
,判断是否是当前线程- 如果不是,获取当前线程的重入次数,将
cachedHoldCounter
设置为当前线程 - 如果是,判断当前重入次数是否为
0
,重新设置当前线程的锁从入信息到readHolds
(ThreadLocal
)中,算是初始化操作,重入次数是0
- 前面两者最后都做
count++
- 如果不是,获取当前线程的重入次数,将
参数解释
HoldCounter:记录线程获取读锁的重入次数
static final class HoldCounter { // 重入次数 int count = 0; // 当前线程id final long tid = getThreadId(Thread.currentThread()); }
readHolds:每个线程都有自己的
readHolds
,基于ThreadLocalMap
,get
方法获取当前线程的HoldCounter
cachedHoldCounter:记录最后一个拿到读锁的线程
firstReader:记录第一个获取读锁的线程
firstReaderHoldCount:记录第一个获取读锁线程的重入次数
上述逻辑源码分析
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
// ===============================================================
// 判断r == 0,当前是第一个拿到读锁资源的线程
if (r == 0) {
// 将firstReader设置为当前线程
firstReader = current;
// 将count设置为1
firstReaderHoldCount = 1;
}
// 判断当前线程是否是第一个获取读锁资源的线程
else if (firstReader == current) {
// 直接++。
firstReaderHoldCount++;
}
// 到这,就说明不是第一个获取读锁资源的线程
else {
// 那获取最后一个拿到读锁资源的线程
HoldCounter rh = cachedHoldCounter;
// 判断当前线程是否是最后一个拿到读锁资源的线程
if (rh == null || rh.tid != getThreadId(current))
// 如果不是,设置当前线程为cachedHoldCounter
cachedHoldCounter = rh = readHolds.get();
// 当前线程是之前的cacheHoldCounter
else if (rh.count == 0)
// 将当前的重入信息设置到ThreadLocal中
readHolds.set(rh);
// 重入的++
rh.count++;
}
// ===============================================================
return 1;
}
return fullTryAcquireShared(current);
}
4.4.3 读锁加锁的后续逻辑fullTryAcquireShared
// tryAcquireShard方法中,如果没有拿到锁资源,走这个方法,尝试再次获取,逻辑跟上面基本一致。
final int fullTryAcquireShared(Thread current) {
// 声明当前线程的锁重入次数
HoldCounter rh = null;
// 死循环
for (;;) {
// 再次拿到state
int c = getState();
// 当前如果有写锁在占用锁资源,并且不是当前线程,返回-1,走排队策略
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
}
// 查看当前是否可以尝试竞争锁资源(公平锁和非公平锁的逻辑)
else if (readerShouldBlock()) {
// 无论公平还是非公平,只要进来,就代表要放到AQS队列中了,先做一波准备
// 在处理ThreadLocal的内存泄漏问题
if (firstReader == current) {
// 如果当前当前线程是之前的firstReader,什么都不用做
} else {
// 第一次进来是null。
if (rh == null) {
// 拿到最后一个获取读锁的线程
rh = cachedHoldCounter;
// 当前线程并不是cachedHoldCounter,没到拿到
if (rh == null || rh.tid != getThreadId(current)) {
// 从自己的ThreadLocal中拿到重入计数器
rh = readHolds.get();
// 如果计数器为0,说明之前没拿到过读锁资源
if (rh.count == 0)
// remove,避免内存泄漏(因为没有拿锁,但是却有ThreadLocal占用资源,直接remove掉)
// 避免原因:每个线程都有自己的readHolds,但是对于将要被阻塞的并且不是重入的线程,readHolds记录的信息没有意义(因为都是初始值),所以先把键值对移除掉
readHolds.remove();
}
}
// 前面处理完之后,直接返回-1
if (rh.count == 0)
return -1;
}
}
// 判断重入次数,是否超出阈值
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// CAS尝试获取锁资源
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
4.4.4 读线程在AQS队列获取锁资源的后续操作
- 正常如果都是读线程来获取读锁资源,不需要使用到AQS队列的,直接CAS操作即可
- 如果写线程持有着写锁,这是读线程就需要进入到AQS队列排队,可能会有多个读线程在AQS中
- 当写锁释放资源后,会唤醒head后面的读线程,当head后面的读线程拿到锁资源后,还需要查看next节点是否也是读线程在阻塞,如果是,直接唤醒
源码分析
// 读锁需要排队的操作
private void doAcquireShared(int arg) {
// 声明Node,类型是共享锁,并且扔到AQS中排队
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 拿到上一个节点
final Node p = node.predecessor();
// 如果prev节点是head,直接可以执行tryAcquireShared
if (p == head) {
int r = tryAcquireShared(arg); //r=1 or r=-1
if (r >= 0) {
// 拿到读锁资源后,需要做的后续处理
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 找到prev有效节点,将状态设置为-1,挂起当前线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
// 拿到head节点
Node h = head;
// 将当前节点设置为head节点
setHead(node);
// 第一个判断更多的是在信号量中处理JDK1.5 BUG的操作,在这里从上面跳过来该判的始终为true
if (propagate > 0 || h == null || h.waitStatus < 0 || (h = head) == null || h.waitStatus < 0) {
// 拿到当前Node的next节点
Node s = node.next;
// 如果next节点是共享锁,直接唤醒next节点
if (s == null || s.isShared())
doReleaseShared();
}
}
4.4.5 读锁的释放锁流程
- 处理重入以及
state
的值 - 唤醒后续排队的
Node
源码分析
// 读锁释放锁流程
public final boolean releaseShared(int arg) {
// tryReleaseShared:处理state的值,以及可重入的内容
if (tryReleaseShared(arg)) {
// AQS队列的事!
doReleaseShared();
return true;
}
return false;
}
// 1、 处理重入问题 2、 处理state
protected final boolean tryReleaseShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 如果是firstReader,直接干活,不需要ThreadLocal
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
}
// 不是firstReader,从cachedHoldCounter以及ThreadLocal处理
else {
// 如果是cachedHoldCounter,正常--
HoldCounter rh = cachedHoldCounter;
// 如果不是cachedHoldCounter,从自己的ThreadLocal中拿
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
// 如果为1或者更小,当前线程就释放干净了,直接remove,避免value内存泄漏
if (count <= 1) {
readHolds.remove();
// 如果已经是0,没必要再unlock,扔个异常
if (count <= 0)
throw unmatchedUnlockException();
}
// --
--rh.count;
}
for (;;) {
// 拿到state,高16位,-1,成功后,返回state是否为0
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
return nextc == 0;
}
}
// 唤醒AQS中排队的线程
private void doReleaseShared() {
// 死循环
for (;;) {
// 拿到头
Node h = head;
// 说明有排队的
if (h != null && h != tail) {
// 拿到head的状态
int ws = h.waitStatus;
// 判断是否为 -1
if (ws == Node.SIGNAL) {
// 到这,说明后面有挂起的线程,先基于CAS将head的状态从-1,改为0
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
// 唤醒后续节点
unparkSuccessor(h);
}
// 这里不是给读写锁准备的(信号量相关)
else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;
}
// 这里是出口
if (h == head)
break;
}
}
五、死锁
5.1 死锁的概念
死锁的定义
多个进程由于竞争资源而造成的阻塞现象,若无外力作用,这些进程将无法继续推进
相似概念:饥饿
等待时间过长以至于给进程推进和响应带来明显影响,”饿而不死“
死锁产生的原因
- 系统资源的竞争
- 进程推进顺序非法
5.2 死锁产生的必要条件(狭义上)
- 互斥条件:一个资源每次只能被一个进程使用
- 不剥夺条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放
- 请求并保持条件:进程已获得的资源,在末使用完之前,不能强行剥夺
- 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系
5.3 死锁的处理策略
5.3.1 死锁的预防
-
破坏互斥条件
- 将只能互斥访问的资源改为同时共享访问
- 将独占锁改为共享锁
缺点
不是所有资源都能改成共享锁的
-
破坏不剥夺(不可抢占)条件
- 请求新资源无法满足时必须释放已有资源
- 由OS协助强制剥夺某进程持有的资源
缺点
- 实现复杂,代价高
- 此操作过多导致原进程任务无法推进
-
破坏请求并保持条件
-
进程开始运行时一次性申请所有资源
缺点
- 资源浪费
- 进程饥饿
-
阶段性请求和释放资源
-
-
破坏循环等待条件
- 对所有资源线性排序,按先后请求资源
- 请求时先低再高
- 释放时先高再低
缺点
- 对资源的编号应相对稳定,限制了新设备增加
- 进程使用资源的顺序可能与系统编号顺序不同
- 限制了用户编程
- 对所有资源线性排序,按先后请求资源
5.3.2 死锁的避免
安全性算法
- 系统安全状态
- 安全状态一定不会出现死锁
- 不安全状态可能出现死锁
- 银行家算法
- 系统预判进程请求是否导致不安全状态
- 是则拒绝请求,否则答应请求
5.3.3 死锁的检测与解除
死锁检测
- 需要一种数据结构,保存有关资源的请求和分配信息
- 提供一种算法,利用这些信息检测是否形成了死锁
死锁解除
- 资源剥夺
- 挂起死锁进程
- 剥夺其资源
- 将资源分配给其他(死锁)进程
- 撤销进程
- 进程回退
- 回退到足以避免死锁的地步
- 需要记录进程历史信息,设置还原点
5.4 死锁案例
案例来源:https://cloud.tencent.com/developer/article/1628870
public class DeadLock {
public static final String LOCK_1 = "lock1";
public static final String LOCK_2 = "lock2";
public static void main(String[] args) {
Thread threadA = new Thread(() -> {
try {
while (true) {
synchronized (DeadLock.LOCK_1) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock1");
Thread.sleep(1000);
synchronized (DeadLock.LOCK_2) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock2");
}
}
}
} catch (Exception e) {
e.printStackTrace();
}
});
Thread threadB = new Thread(() -> {
try {
while (true) {
synchronized (DeadLock.LOCK_2) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock2");
Thread.sleep(1000);
synchronized (DeadLock.LOCK_1) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock1");
}
}
}
} catch (Exception e) {
e.printStackTrace();
}
});
threadA.start();
threadB.start();
}
}
如上述代码所示,我们启动了两个线程,在每个线程中都要获得DeadLock.LOCK_1
和DeadLock.LOCK_2
,其中
threadA
,先获取DeadLock.LOCK_1
,再获取DeadLock.LOCK_2
threadB
,先获取DeadLock.LOCK_2
,再获取DeadLock.LOCK_1
这样,当threadA
获取到DeadLock.LOCK_1
之后,就要去获取DeadLock.LOCK_2
,而DeadLock.LOCK_2
则是先被threadB
获取了,因此threadA
就需要等待threadB
释放DeadLock.LOCK_2
之后才能继续执行;但是threadB
在获取到DeadLock.LOCK_2
之后,却是在等待threadA
释放DeadLock.LOCK_1
,因此这就形成了“循环等待条件”,从而形成了死锁。想要解决这个死锁很简单,我们只需要让threadA
和threadB
获取DeadLock.LOCK_1
和DeadLock.LOCK_2
的顺序相同即可,例如:
public class DeadLock {
public static final String LOCK_1 = "lock1";
public static final String LOCK_2 = "lock2";
public static void main(String[] args) {
Thread threadA = new Thread(() -> {
try {
while (true) {
synchronized (DeadLock.LOCK_1) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock1");
Thread.sleep(1000);
synchronized (DeadLock.LOCK_2) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock2");
}
}
}
} catch (Exception e) {
e.printStackTrace();
}
});
Thread threadB = new Thread(() -> {
try {
while (true) {
synchronized (DeadLock.LOCK_1) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock2");
Thread.sleep(1000);
synchronized (DeadLock.LOCK_2) {
System.out.println(Thread.currentThread().getName() + " 锁住 lock1");
}
}
}
} catch (Exception e) {
e.printStackTrace();
}
});
threadA.start();
threadB.start();
}
}
除此之外,还有一种解决方法,那就是让DeadLock.LOCK_1
和DeadLock.LOCK_2
的值相同,例如:
public static final String LOCK_1 = "lock";
public static final String LOCK_2 = "lock";
这是为什么呢?因为字符串有一个常量池,如果不同的线程持有的锁是具有相同字符的字符串锁时,那么两个锁实际上就是同一个锁