一、锁的分类
1.1 可重入锁，不可重入锁
java中提供的synchronized，RenntrantLock， ReentrantReadWriteLock都是可重入锁
重入： 当前线程获取到A锁，在获取之后尝试再次获取A锁是可以直接拿到的
不可重入： 当前线程获取到A锁，在获取之后尝试再次获取A锁，无法获取到的，因为A锁被当前线程占用着，需要等待自己释放锁在获取锁
1.2 乐观锁，悲观锁
Java中提供的synchronzied，ReentrantLock， R蒽蒽trantReadWriteLock都是悲观锁
Java中提供的CAS操作，就是乐观锁的一种实现
**悲观锁：**获取不到锁资源时，会将当前线程挂起（进入BLOCKED
,WAITING）,线程挂起会涉及到用户态和内核态的切换，而这种切换时比较消耗资源的
- 用户态：JVM可以自行执行的指令，不需要借助操作系统执行
- 内核态：JVM不可以自行执行，需要操作系统才可以执行
**乐观锁：**获取不到锁资源，可以再次让CPU调度，重新尝试获取锁资源。Atomic原子类中，就是基于CAS乐观锁实现的
1.3 公平锁，非公平锁
java中提供的synchronzied只能是非公平锁
Java中提供的ReentrantLock，ReentrantReadWriteLock可以实现公平锁和非公平锁
公平锁： 线程A获取到锁资源，线程B没有拿到，线程B去排队，线程C来了，锁被A持有，同时线程B在排队，直接排到B的后面，等待B拿到锁资源或者是B取消后，才可以尝试去竞争锁资源
非公平锁： 线程A获取到锁资源，线程B没有拿到，线程B去排队，线程C来了，先尝试竞争一波
- 拿到锁资源，插队成功
- 没有拿到锁资源，依然要排到B的后面，等待B拿到锁资源或者B取消后，才可以尝试去竞争锁资源
1.4 互斥锁，共享锁
Java中提供的synchronized，ReentrantLock都是互斥锁
java中提供的ReentrantReadWriteLock有互斥锁也有共享锁
互斥锁： 同一时间点，只会有一个线程持有着当前互斥锁
共享锁： 同一时间点，当前共享锁可以被多个线程同时持有
二、深入synchronized
2.1 类锁，对象锁
synchronzied的使用一般是同步方法和同步代码块
synchronzied的锁是基于对象实现的
如果使用同步方法
- static：此时使用的是当前类.class作为锁（类锁）
- 非static：此时使用的是当前对象作为锁（对象锁）
public class MiTest {
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("1111");
}
public synchronized void b(){
System.out.println("2222");
}
}
2.2 synchronzied的优化
在JDK1.5的时候，Doug lee推出了ReentrantLock，lock的性能远高于synchronzied，所以JDK团队就在JDK1.6中，对synchronzied做了大量的优化
锁消除： 在synchronzied修饰的代码中，如果不存在操作临界资源的情况，会触发锁消除，即便写了synchronzied也不会触发
public synchronzied void method(){
// 没有操作临界资源
// 此时这个方法的synchronzied你可以认为没有
}
锁膨胀： 如果在一个循环中，频繁的获取和释放锁资源，这样带来的消耗很大，锁膨胀就是将锁的范围扩大，避免频繁的竞争和获取锁资源带来不必要的消耗
public void method(){
for(int i = 0;i < 999999;i++){
synchronized(对象){
}
}
// 这是上面的代码会触发锁膨胀
synchronized(对象){
for(int i = 0;i < 999999;i++){
}
}
}
锁升级： ReentrantLock的实现，是先基于乐观锁的CAS尝试获取锁资源，如果拿不到锁资源，才会挂起线程，synchronzied在JDK1.6之前，完全就是获取不到锁，立即挂起当前线程，所以synchronzied性能比较差
synchronzied就在JDK1.6做了锁升级的优化
-
无锁，匿名偏向： 当前对象没有作为锁存在
-
偏向锁： 如果当前锁资源，只有一个线程在频繁的获取和释放，那么这个线程过来，就只需要判断，当前指向的线程是否是当前线程
- 如果是，直接拿着锁资源走
- 如果当前线程不是我，基于CAS的方式，尝试将偏向锁指向当前线程，如果获取不到，触发锁升级，升级为轻量级锁（偏向锁状态出现锁竞争的情况）
-
**轻量级锁：** 会采用自旋锁的方式去频繁的以CAS的形式获取锁资源（采用的是自适应自旋锁）- 如果成功获取到，拿着锁资源走
- 如果自旋到了一定次数，没拿到锁资源，升级为重量级锁
-
重量级锁： 就是最传统的snychronzied方式，拿不到锁资源，就挂起当前线程（用户态&内核态）
2.3 synchronized实现原理
synchronzied是基于对象实现的
先要对java对象在堆内存的存储有一个了解
展开MarkWord
MarkWord中标记着四种锁的信息：无锁，偏向锁，轻量级锁，重量级锁
2.4 synchronized的锁升级
锁默认情况下，开启了偏向锁延迟
偏向锁在升级为轻量级锁时，会涉及到偏向锁撤销，需要等待一个安全点（STW）才可以做偏向锁撤销，在明知道有并发情况下，就可以选择不开启偏向锁，或者时设置偏向锁延迟开启
因为JVM在启动时，需要加载大量的.class文件到内存中，这个操作会涉及到synchronzied的使用，为了避免出现偏向锁撤销操作，JVM启动初期，有一个延迟4s开启偏向锁的操作
如果正常开启偏向锁了，那么就不会出现无锁状态，对象会直接变为匿名偏向。
public static void main(String[] args) throws InterruptedException {
Thread.sleep(5000);
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
new Thread(() -> {
synchronized (o){
//t1 - 偏向锁
System.out.println("t1:" + ClassLayout.parseInstance(o).toPrintable());
}
}).start();
//main - 偏向锁 - 轻量级锁CAS - 重量级锁
synchronized (o){
System.out.println("main:" + ClassLayout.parseInstance(o).toPrintable());
}
}
整个锁升级状态的转变
Lock Record以及ObjectMonitor存储的内容
2.5 重量级锁底层ObjectMonitor
需要去找Openjdk，找到ObjectMointor的两个文件 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;
}
查看几个C++中实现的加锁流程
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-entry
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);
}
Enterl
for (;;) {
// 入队
node._next = nxt = _cxq ;
// 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和synchronzied的区别
核心区别：
ReentrantLock是一个类，synchronized是关键字，当然都是在jvm层面实现互斥锁的方式。
效率区别：
如果竞争比较激烈，推荐ReentrantLock去实现，不存在锁升级概念，而synchronzied是存在锁升级概念的，如果升级到重量级锁，是不存在锁降级的
底层实现区别：
实现原理不一样，ReentrantLock是基于AQS实现的，synchronzied是基于ObjectMointor实现的
功能的区别：
ReentrantLock的功能比synchronzied更全面
- ReentrantLcok支持公平锁和非公平锁
- ReentrantLock可以指定等待锁资源的时间
选择哪个：如果你对并发编程特别熟练，推荐使用ReentranLcok，功能更丰富，如果掌握一般，使用synchronzied更好
3.2 AQS概述
AQS就是AbstractQueuedSynchronzied抽象类，AQS其实就是JUC包下的一个基类，JUC下的很多内容都是AQS实现了部分功能，比如ReentrantLock，ThreadPoolExcutor，阻塞队列，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;
}
AQS内部结构和属性
3.3 加锁流程源码剖析
3.3.1 加锁流程概述
这个是非公平锁的流程
3.3.2 三种加锁源码分析
3.3.2.1 lock方法
1、执行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);
}
2、acquire方法，公平锁和非公平锁逻辑是一样的
public final void acquire(int arg) {
// tryAcquire再次查看，当前线程是否可以尝试获取锁资源
if (!tryAcquire(arg) &&
// 没有拿到锁资源
// addWaiter(Node.EXCLUSIVE)：将当前线程封装为Node节点，插入到AQS双向链表的结尾
// acquireQueued：查看我是否是第一个排队的节点，如果是可以再次尝试获取锁资源，如果长时间拿不到，挂起线程
// 如果不是第一个排队的节点，就尝试挂起线程即可
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
// 中断线程的操作
selfInterrupt();
}
3、 tryAcquire方法竞争锁资源的逻辑，分为公平锁和非公平锁
// 非公平锁实现
final boolean nonfairTryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取state值
int c = getState();
// 判断state是否为0，如果为0证明之前持有锁的线程释放了锁资源
if (c == 0) {
// 尝试抢一波锁，将state的值从0改为1
if (compareAndSetState(0, acquires)) {
// 将当前线程设置到exclusiveOwnerThread属性，代表是当前线程持有着锁资源
setExclusiveOwnerThread(current);
// 拿锁成功返回true
return true;
}
}
// 不是0，有线程持有锁资源
// 如果持有锁资源的是当前线程，证明是锁重入操作
else if (current == getExclusiveOwnerThread()) {
// 将state + 1
int nextc = c + acquires;
// 如果state+1小于0，证明超过了int类型的最大值
// 重入的次数超过了界限，抛出异常
if (nextc < 0)
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();
// 获取state的值
int c = getState();
// 判断state是否为0
if (c == 0) {
// 查看AQS中是否有排队的Node
// 没人排队抢一手，如果有人排队，如果我是第一个，也抢一手
if (!hasQueuedPredecessors() &&
// 如果满足上个条件尝试CAS将state的值从0改为1
compareAndSetState(0, acquires)) {
// 将当前线程设置到exclusiveOwnerThread属性，代表是当前线程持有着锁资源
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;
}
public final boolean hasQueuedPredecessors() {
// 获取到尾节点
Node t = tail;
// 获取头节点
Node h = head;
Node s = h.next;
// 如果头尾节点相等，证明没有线程在AQS队列中排队，直接去抢占锁资源
return h != t &&
// 如果头节点的下一个节点不为null，并且该节点的线程不为当前线程（说明排在AQS队列第一名的不是我）
((s == null || s.thread != Thread.currentThread());
}
4、addWaiter方法，将没有拿到锁资源的线程扔到AQS队列中去排队
// 没有拿到锁资源的线程过来排队，mode：代表互斥锁
private Node addWaiter(Node mode) {
// 将当前线程封装为Node对象
Node node = new Node(Thread.currentThread(), mode);
// 拿到尾节点
Node pred = tail;
// 如果尾节点不为null，证明当前AQS队列中存在节点
if (pred != null) {
// 将当前节点的前继指针指向尾节点
node.prev = pred;
// 以CAS的方式将当前线程设置为tail节点
if (compareAndSetTail(pred, node)) {
// 将原尾节点的后继指针指向当前节点
pred.next = node;
// 然后当前节点Node对象
return node;
}
}
// 如果CAS失败，以死循环的方式，保证当前线程的Node对象一定可以放到AQS队列的末尾
enq(node);
return node;
}
private Node enq(final Node node) {
for (;;) {
// 拿到尾节点
Node t = tail;
// 如果尾节点为null，AQS中一个节点都没有，构建一个伪结点，作为head和tail
if (t == null) {
// 以CAS方式创建一个Node对象的伪结点
if (compareAndSetHead(new Node()))
// 头尾节点都为该伪结点
tail = head;
} else {
// 如果t不为null，证明AQS队列中有节点
// 将当前节点的前继指针指向尾节点
node.prev = t;
// 以CAS方式将当前线程设置为tail节点
if (compareAndSetTail(t, node)) {
// 将原尾节点的后继指针指向当前节点
t.next = node;
return t;
}
}
}
}
5、acquireQueued方法，判断当前线程是否还能再次尝试获取锁资源，如果不能再次获取锁资源或者又没获取到，尝试将当前线程挂起
// 当前没有拿到锁资源后，并且到AQS排队了之后触发的方法，中断操作这里不用考虑
final boolean acquireQueued(final Node node, int arg) {
// 不考虑中断
// failed：获取锁资源是否失败标识
boolean failed = true;
try {
// 中断暂不涉及
boolean interrupted = false;
// 死循环
for (;;) {
// 拿到当前节点的前继节点
final Node p = node.predecessor();
// 如果前继节点为头节点，说明排在第一位，再次尝试抢一波锁资源
if (p == head && tryAcquire(arg)) {
// 获取锁资源成功
// 将头节点设置为当前获取锁资源成功的节点，并取消thread信息
setHead(node);
// 将原头节点的后继节点置为null，方便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);
}
}
// 拿到前继节点
final Node predecessor() throws NullPointerException {
// 获取前继节点
Node p = prev;
// 如果前继节点为空，抛出空指针异常
if (p == null)
throw new NullPointerException();
else
// 返回前继节点
return p;
}
// 获取锁资源成功后，先执行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;
// 判断状态是否为-1
if (ws == Node.SIGNAL)
// 返回true，代表当前节点可以安心挂起线程
return true;
// 如果状态大于0，则状态为1，代表前继节点取消了
if (ws > 0) {
// 如果当前节点的上一个节点是取消状态，我需要往前找到一个状态不为1的Node，作为他的prev前继节点
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
// 找到不为1的前继节点后，将其前继节点的后继指针指向当前节点
pred.next = node;
} else {
// 前继节点状态不是1或者-1，那该前继节点的状态就为0正常状态，则将该前继节点的状态以CAS方式从0改为-1
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
3.3.2.2 tryLock方法
1、tryLock()方法
// tryLock方法,无论是公平锁还是非公平锁，都会走非公平锁抢占锁资源的操作
// 就是拿到state的值，如果是0，直接CAS抢一波
// state不是0那就看是不是锁重入操作
// 如果没抢到，或者不是锁重入操作，告辞，返回flase
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
final boolean nonfairTryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取state的值
int c = getState();
// 如果state的值为0
if (c == 0) {
// 以CAS方式将state的值从0改为1。
if (compareAndSetState(0, acquires)) {
// 抢占锁资源成功，将当前线程设置到exclusiveOwnerThread属性，代表是当前线程持有着锁资源
setExclusiveOwnerThread(current);
// 返回true，抢占锁资源成功
return true;
}
}
// 如果state不为0，判断当前线程是否为持有锁的线程，判断是否属于锁重入操作
else if (current == getExclusiveOwnerThread()) {
// state+1
int nextc = c + acquires;
// 如果state的值小于0，说明锁重入次数超过了int的最大值，抛出异常
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
// 否则将设置state的值
setState(nextc);
// 返回true，锁重入成功
return true;
}
// 锁资源抢占失败，返回false
return false;
}
2、tryLock（time， unit）
- 第一波分析，类似的代码
// tryLock（long timeout, TimeUnit unit）执行的方法
public boolean tryLock(long timeout, TimeUnit unit)throws InterruptedException {
// unit.toNanos(timeout)会把设置的等待时间转换为纳秒
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
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 (;;) {
// 获取当前节点的前继节点
final Node p = node.predecessor();
// 如果前继节点为头节点，说明当前节点是AQS队列中排第一位的，直接尝试抢一波
if (p == head && tryAcquire(arg)) {
// 抢锁资源成功，返回true
setHead(node);
p.next = null;
拿锁失败标记位，修改为false
failed = false;
return true;
}
// 结算剩余的可用时间
nanosTimeout = deadline - System.nanoTime();
// 判断是否用尽时间
if (nanosTimeout <= 0L)
// 用尽返回false，拿锁失败
return false;
// shouldParkAfterFailedAcquire：根据上个节点的状态来确定是否可以挂起线程
if (shouldParkAfterFailedAcquire(p, node) &&
// 如果剩余时间小于1000L，就不用挂起线程了
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;
// 不是head的后继节点，有可能是中间节点
if (pred != head &&
// 拿到上个节点的状态，只要上一个节点的状态不是取消状态，改为-1
((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 {
// 当前节点是head的后继节点
unparkSuccessor(node);
}
// 自己指向自己，方便GC回收
node.next = node;
}
}
3.3.2.3 lockInterruptibly方法
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public final void acquireInterruptibly(int arg)throws InterruptedException {
// 判断线程的中断标记为，如果被修改为true，抛出异常
if (Thread.interrupted())
throw new InterruptedException();
// 尝试抢一波
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
// 这个是lockInterruptibly和tryLock（time， unit）唯一的区别
// lockInterruptibly，拿不到锁资源，就死等，等到锁资源释放后，被唤醒，或者是被中断唤醒
private void doAcquireInterruptibly(int arg)throws InterruptedException {
// 添加到AQS队列的尾部
final Node node = addWaiter(Node.EXCLUSIVE);
// 拿锁失败标记位
boolean failed = true;
try {
// 死循环
for (;;) {
// 拿到当前节点的前继节点
final Node p = node.predecessor();
// 如果前继节点为head，说明当前节点排在第一位，尝试抢一波锁资源
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;
// 头节点不为null，说明有排队
// 如果h的状态不为0（为-1），说明后面有排队，并且线程已经被挂起了
if (h != null && h.waitStatus != 0)
// 唤醒排队的线程
unparkSuccessor(h);
return true;
}
return false;
}
// ReentrantLock释放锁资源操作
protected final boolean tryRelease(int releases) {
// state-1
int c = getState() - releases;
// 如果当前线程不是持有所得线程，抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
free，代表当前锁资源是否释放干净
boolean free = false;
// 如果state-1后的值为0，代表释放干净了
if (c == 0) {
free标志位修改为true
free = true;
// 将持有锁的线程置为null
setExclusiveOwnerThread(null);
}
// 将c的值给state
setState(c);
// 锁资源释放干净返回true，否则返回false
return free;
}
private void unparkSuccessor(Node node) {
// 获取当前节点的状态
int ws = node.waitStatus;
// 判断当时阶段状态是否小于0（即判断是否为-1）
if (ws < 0)
先基于CAS，将节点的状态从-1改为0
compareAndSetWaitStatus(node, ws, 0);
// 找到当前节点的后继节点
Node s = node.next;
// 如果后继节点为null，或者后继节点的状态大于0（即为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只是为了更方便的操作，方便管理双向链表而已，一个烧饼节点的存在
比如ReentrantLcok中释放锁资源时，会考虑是否需要唤醒后继节点，如果头节点的状态不是-1，就不需要去唤醒后继节点，唤醒后继节点时，需要找到head.next节点，如果head.next为null，或者时取消了，此时需要遍历整个双向链表，从后往前遍历，找到离head最近的Node，规避了一些不必要的唤醒操作。
如果不用虚拟节点，当前节点挂起，当前节点的状态设置为-1，这样也可行，AQS本上就是使用哨兵节点做双向链表的一些操作
网上说，虚拟的head可以避免重复唤醒操作，虚拟的head并没有处理这个问题
3.5.2 AQS中为什么使用双向链表
AQS的双向链表就是为了更方便的操作Node节点
在执行tryLock，lockInterruptibly方法时，如果在线程阻塞时，中断了线程，此时线程会执行cancelAcquire取消当前节点，不在AQS的双向链表中排队，如果是单向链表，此时会导致取消节点，无法直接将当前节点的前继节点的next指针，指向当前节点的next节点
3.6 ConditionObject
3.6.1 ConditionObject的介绍和应用
像synchronzied提供wait和notify的方式是线程在持有锁时，可以实现挂起，以及唤醒的操作
ReentrantLock也有用这样的功能
ReentrantLcok提供了await和signal方法去实现类似wait和notify的功能
想执行await或者是signal就必须现持有lock锁资源
先看一下Condition的应用
public static void main(String[] args) throws InterruptedException, IOException {
ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
new Thread(() -> {
lock.lock();
System.out.println("子线程获取锁资源并await挂起线程");
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("子线程挂起后被唤醒！持有锁资源");
}).start();
Thread.sleep(100);
// =================main======================
lock.lock();
System.out.println("主线程等待5s拿到锁资源，子线程执行了await方法");
condition.signal();
System.out.println("主线程唤醒了await挂起的子线程");
lock.unlock();
}
3.6.2 Condition的构建方式&核心属性
发现在通过lock锁对象执行newCondition方法时，本质就是直接new的AQS提供的ConditionObject对象
final ConditionObject newCondition() {
return new ConditionObject();
}
其实lock锁中可以有多个Condition对象
在对Condition1进行操作时，不会影响到Conditon2的单向链表
其次可以发现ConditionObject中，有两个核心属性
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;
虽然Node对象有prev和next，但是在ConditonObject中是不会使用这两个属性的，只要早Conditon队列中，这两个属性都是null，在ConditonObject中只会使用nextWaiter的属性实现单向链表的效果
3.6.3 Conditon的await方法分析（前置分析）
持有锁的线程在执行await方法后会做几个操作
- 判断线程是否中断，如果中断了，什么都不做
- 如果没有中断，就将当前线程封装为Node添加到Condition的单项链表中
- 一次性释放掉锁资源
- 如果当前线程没有在AQS队列中，就正常执行LockSupport.park(this)挂起线程
// await方法的前置分析，只分析到线程挂起
public final void await() throws InterruptedException {
// 先判断线程的中断标记位是否时true
if (Thread.interrupted())
// 如果为true，就没必要执行后续线程挂起操作
throw new InterruptedException();
// 在线程挂起之前，先将当前线程封装为Node，并且添加到Conditon队列中
Node node = addConditionWaiter();
// fullyRelease在释放锁资源，一次性将锁资源全部释放，并且保留重入的次数
int savedState = fullyRelease(node);
// 省略一行代码。。。。。。
// 当前Node是否在AQS队列中？
// 执行fullyRelease方法后，线程就释放锁资源了，如果线程刚刚释放锁资源，其他线程就立即指向signal方法
// 此时当前线程就被放到了AQS队列中，这样一来线程就不需要执行LockSupport.park(this)，去挂起线程了
while (!isOnSyncQueue(node)) {
// 如果没有在AQS队列中，正常在Condition单向链表里，正常挂起线程
LockSupport.park(this);
// 省略部分代码。。。。
}
// 省略部分代码
}
// 线程挂起前，添加到Conditon单向链表
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;
// 如果头节点不为null，正常执行
while (t != null) {
// 拿到t的next节点
Node next = t.nextWaiter;
// 如果头节点的状态不为-2，说明有问题
if (t.waitStatus != Node.CONDITION) {
// 头节点的next为null
t.nextWaiter = null;
如果trail为null，代表头节点状态就是1
if (trail == null)
// 将头节点指向next节点
firstWaiter = next;
else
// 如果trail有值，说明不是头节点位置
trail.nextWaiter = next;
// 如果next为null，说明单向链表遍历到最后了，直接结束2
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 {
// 获取到第二个节点，并且将第二个节点设置为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 Conditon的await方法分析（后置分析）
分为几个部分：
-
唤醒之后，要先确认是中断唤醒还是signal唤醒，还是signal唤醒之后被中断
-
确保当前线程的Node已经在AQS队列中
-
执行acquireQueued方法，等待锁资源
-
在获取锁资源后，要确定是否在获取锁资源的阶段被中断过，如果被中断过，并且不是THROW_IE，那就确保interruptMode是REINTERRUPT
-
确认当前Node已经不在Conditon队列中
-
最终根据interruptMode来决定做具体的事情
- 0： 什么也不做
- THROW_IE：抛出异常
- REINTERRUPT：执行线程的interrupt方法
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）：siganl唤醒，但是线程被中断了，并且可以确保在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单向链表中，但是后续被中断过
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;
}
// 判断线程到底是中断唤醒，还是sginal唤醒的
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队列在处理
Thread.yield();
return false;
}
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 (;;) {
// 如果当前节点是尾节点
if (t == node)
// 返回true
return true;
// 如果尾节点为null，证明AQS队列中没有节点
if (t == null)
// 返回false
return false;
// 从后往前依次找节点
t = t.prev;
}
}
private void reportInterruptAfterWait(int interruptMode)throws InterruptedException {
// 如果是被中断唤醒的await，直接抛出异常
if (interruptMode == THROW_IE)
throw new InterruptedException();
// 如果是signal唤醒，后续被中断了
else if (interruptMode == REINTERRUPT)
// 确认线程的中断标记位是true
// Thread.currentThread().interrupt();
selfInterrupt();
}
3.6.6 Conditon的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是唤醒一个，这个是全部唤醒
// 以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
一、为什么要出现读写锁
synchronized和ReentrantLock都是互斥锁。
如果有一个操作是读多写少，还要保证线程安全的话，如果采用上述的两种互斥锁，效率方面会很低
在这种情况下，就可以使用ReentrantReadWriteLock读写锁去实现
读读之间不互斥，可以读和读操作并发执行
但是如果涉及到写操作，那么还得是互斥的操作
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
readLock.lock();
try {
System.out.println("子线程！");
try {
Thread.sleep(500000);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
readLock.unlock();
}
}).start();
Thread.sleep(1000);
writeLock.lock();
try {
System.out.println("主线程！");
} finally {
writeLock.unlock();
}
}
二、读写锁的实现原理
ReentrantReadWriteLock还是基于AQS实现的，还是对state进行操作，拿到锁资源就去干活，如果没有拿到，依然去AQS队列中排队
读锁操作： 基于state的高16进行操作
写锁操作： 基于state的低16进行操作
ReentrantReadWriteLock依然是可重入锁
写锁重入： 读写锁中的写锁的重入方式，基本和ReentrantLock一致，没有什么区别，依然对state进行+1操作即可，只要确认持有锁资源的线程是当前写锁线程即可，只不过之前ReentranLock的重入次数是state的正数取值范围，但是读写锁中写锁范围就变小了
**读锁重入：**因为读锁是共享锁，读锁在获取锁资源操作时，是要对state的高16为进行+1操作，因为读锁是共享锁，所以同一时间会有多线读线程持有读锁资源，这样一来，多个读操作在持有读锁时，无法确认每一个线程读锁重入的次数，为了去记录读锁重入的次数，每个读操作的线程，都会有一个ThradLocal记录锁重入次数
写锁的饥饿问题： 读锁时共享锁，当有线程持有读锁资源时，再来一个线程想要获取读锁，直接对state修改即可，在读锁资源先被占用后，来一个写锁资源，此时，大量的需要获取读锁的线程来请求锁资源，如果可以绕过写锁，直接拿资源，会造成写锁长时间无法获取到写锁资源
读锁在拿到锁资源后，如果再有读线程需要获取读锁资源，需要去AQS队列排队，如果队列的前面有需要写锁资源的线程，那么后续读线程时无法拿到锁资源的，持有读锁的线程，只会让写锁线程之前的读线程拿到锁资源
三、写锁分析
3.1 写锁加锁流程概述
- 写线程来竞争写锁资源
- 写线程会直接通过tryAcquire获取写锁资源（公平锁&非公平锁）
- 获取state的值，并且拿到低16的值
- 如果state值不为0，判断是否是锁重入操作，判断当前持有写锁的线程是否是当前线程
- 如果state为0
5.1 判断是否是公平锁：查看队列是否有排队的，有直接告辞，没有就抢一手
5.2 判断是否是非公平锁，直接抢一手 - 如果拿到锁资源，直接告辞，如果没有拿到去排队，而排队的逻辑和ReentrantLock一样
3.2 写锁加锁源码分析
// 写锁加锁的入口
public void lock() {
sync.acquire(1);
}
// 逻辑和ReentranLock是一致的，只有tryAcquire()方法有区别
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);
// 如果state的值不为0
if (c != 0) {
如果state低16为0，没有线程持有写锁，读写互斥，或者持有锁的线程不是当前线程
if (w == 0 || current != getExclusiveOwnerThread())
// 直接告辞
return false;
// 当前线程持有写锁，锁重入
// 判断 state低16位 + 1 是否超过锁重入次数，超过抛异常
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// state + 1
setState(c + acquires);
// 返回true获取写锁成功
return true;
}
// 尝试获取锁资源
if (writerShouldBlock() ||
// CAS拿锁
!compareAndSetState(c, c + acquires))
return false;
// 拿锁成功，设置占有互斥锁的线程
setExclusiveOwnerThread(current);
// 返回true获取写锁成功
return true;
}
// ================================================================
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
state & (1 << SHARED_SHIFT) - 1
00000000 0000000 00000000 00000001 == 1
00000000 0000001 00000000 00000000 == 1 << 16
00000000 0000000 11111111 11111111 == (1 << 16) -1
&运算，有0则为0，都是1才为1，所以这样可以直接拿到低16的值
//=================================================================
writerShouldBlock方法查看公平锁和非公平锁的效果
// 非公平锁，直接返回false，直接尝试CAS抢一波
final boolean writerShouldBlock() {
return false;
}
// 公平锁
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
// 判断当前AQS队列中有没有人排队，如果有排队我是否排在第一位，如果满足就尝试抢一波
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
3.3 写锁释放锁流程概述&释放锁源码
释放的流程和ReentrantLock一致，只是在判断判断是否释放干净时，判断低16的值
// 释放锁资源入口
public void unlock() {
sync.release(1);
}
// 释放锁流程
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
// 写锁释放锁的tryRelease方法
protected final boolean tryRelease(int releases) {
// 判断当前持有写锁的线程是否时当前线程，不是则抛出异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// state - 1
int nextc = getState() - releases;
// 判断低16的值是否为0
boolean free = exclusiveCount(nextc) == 0;
if (free)
// 如果低16的值为0，证明写锁资源释放干净，将持有所得线程设置为null
setExclusiveOwnerThread(null);
// 设置给state
setState(nextc);
// 释放干净，返回true
// 如果写锁有重入，这里返回false，不去释放排队的Node
return free;
}
四、读锁分析
4.1 读锁加锁流程概述
- 分析读锁加锁的基本流程
- 分析读锁的可重入锁实现以及优化
- 解决TheadLocal内存泄漏问题
- 读锁获取锁资源后，如何唤醒AQS中排队的读线程
4.1.1 基本读锁流程
- 读线程竞争读锁资源
- 会竞争共享锁的资源
- 拿到state
- 判断state中的低16位是否为0
- 如果不为0，代表有写锁占用着资源
- 如果有写锁占用资源，但是不是当前线程，告辞【写锁-读锁的降级】
- 拿到state的高16位的值
- 公平锁：如果有人排队，直接拜拜，去排队
- 非公平锁：查看AQS的队列中，是否有写线程在排队，如果有，去排队
- CAS对state的高16位 + 1
- 如果成功，拿到读锁资源
针对上诉简单逻辑的源码分析
// 读锁加锁方法入口
public void lock() {
sync.acquireShared(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位【无符号左移16位，获取高16的值】
int r = sharedCount(c);
// 公平锁：查看队列是否有排队的，有排队的，直接告辞，进不去if，后面也不用判断
// 非公平锁：没有排队的直接抢，有排队的，但是读锁其实不需要排队，如果出现这个情况，大部分时写锁资源刚刚释放
if (!readerShouldBlock() &&
// 判断持有读锁的临界值是否达到
r < MAX_COUNT &&
// CAS修改state，对高16进行+1
compareAndSetState(c, c + SHARED_UNIT)) {
// 省略部分代码。。。。
return 1;
}
return fullTryAcquireShared(current);
}
// 非公平锁判断
final boolean readerShouldBlock() {
return apparentlyFirstQueuedIsExclusive();
}
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，可以直接抢占锁资源
}
// ===================================================================================
// 公平锁判断
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
// 判断AQS队列是否有排队，如果有排队，自己是否处于第一位，如果满足尝试抢一波锁资源
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
4.1.2 读锁重入流程
============================= 重入操作 ================
前面阐述过，读锁为了记录锁重入的次数，需要让每个读线程用ThreadLocal存储重入次数
ReentrantReadWriteLock对读锁重入做了一些优化操作
============================ 记录重入次数的核心 ================
ReentrantReadWriteLock在内部对ThreadLocal做了封装，基于HoldCount的对象存储重入次数，在内部有个count属性记录，而且每个线程都有自己的ThreadLockHoldCounter，所以可以直接对内部的count进行++操作
============================= 第一个获取读锁资源的重入次数记录方式 ================
第一个拿到读锁资源的线程，不需要通过ThreadLocal存储，内部提供了两个属性来记录第一个拿到读锁资源线程的信息
内部提供了firstReader记录第一个拿到读锁资源的线程，firstReaderHoldCount记录firstReader的锁重入有次数
========================= 最后一个获取读锁资源的重入次数记录方式 ================
最后一个拿到读锁资源的线程，也会缓存他的重入次数，这样++起来更方便
基于cachedHoldCounter缓存最后一个拿到读锁资源的重入次数
重入次数的流程执行方式
-
判断当前线程是否是第一个拿到读锁资源的：如果是，直接将firstReader以及firstReaderHoldCount设置为当前线程的信息
-
判断当前线程是否是firstReader：如果是，直接对firstReaderHoldCount++即可
-
跟firstReader没有关系了，先获取cachedHoldCounter，判断是否是当前线程
- 如果不是，获取当前线程的重入次数，将cachedHoldCounter设置为当前线程
- 如果是，判断当前重入次数是否为0，重新设置当前线程的锁重入信息到ThradLocal中，算是初始化操作，重入次数是0
- 前面两者最后都做count++
上述逻辑源码分析
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，如果是0当前是第一个拿到读锁资源的线程
if (r == 0) {
// firstReader设置为当前线程
firstReader = current;
// firstReaderHoldCount 设置为1
firstReaderHoldCount = 1;
// 判断当前线程是否是第一个获取读锁资源的线程
} else if (firstReader == current) {
// firstReaderHoldCount + 1
firstReaderHoldCount++;
// 到这里，说明当前线程不是第一个获取到读锁资源的线程
} else {
// 获取最后一个拿到读锁资源的线程
HoldCounter rh = cachedHoldCounter;
// 如果最后拿到读锁资源的线程不是当前线程
if (rh == null || rh.tid != getThreadId(current))
// 设置当前线程为cachedHoldCounter
cachedHoldCounter = rh = readHolds.get();
// 如果最后拿到读锁资源的是当前线程，count为0
else if (rh.count == 0)
// 将当前的重入信息设置到ThreadLocal中
readHolds.set(rh);
重入++
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current);
}
4.1.3 读锁加锁的后续逻辑fullTryAcquireShared
// tryAcquireShard方法中，如果没有拿到锁资源吗，走这个方法让，尝试再次获取，逻辑跟上面基本一致
final int fullTryAcquireShared(Thread current) {
// 声明当前线程的锁重入次数
HoldCounter rh = null;
// 死循环
for (;;) {
// 获取state的值
int c = getState();
// 判断state低16不为0，说明当前有写锁占用资源
if (exclusiveCount(c) != 0) {
// 占用读锁的线程不是当前线程，返回-1，去排队
if (getExclusiveOwnerThread() != current)
return -1;
// 查看当前是否可以尝试竞争锁资源（公平锁和非公平锁逻辑）
} else if (readerShouldBlock()) {
// 无论是公平还是非公平，只要进来，就代表要放到AQS队列中，先做一波准备
// 在处理ThradLocal的内存泄漏问题
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，避免内存泄漏
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.1.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 (;;) {
// 拿到Node的上一个节点
final Node p = node.predecessor();
// 如果上一个节点为头节点
if (p == head) {
// 尝试抢一波读锁资源
int r = tryAcquireShared(arg);
// 获取到读锁资源
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null;
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的操作
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.2 读锁的释放锁流程
1、处理重入以及state的值
2、唤醒后续排队的Node
public void unlock() {
sync.releaseShared(1);
}
// 读锁释放锁流程
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，直接处理
if (firstReader == current) {
// 如果重入次数为1
if (firstReaderHoldCount == 1)
// firstReader设置为null
firstReader = null;
else
// 否则重入次数 - 1
firstReaderHoldCount--;
// 到这里说明不是第一个获取读锁资源的线程
} else {
// 获取cachedHoldCounter
HoldCounter rh = cachedHoldCounter;
// 如果当前线程不是最后一个获取读资源的线程
if (rh == null || rh.tid != getThreadId(current))
// 获取ThreadLocal
rh = readHolds.get();
// 获取其重入次数
int count = rh.count;
// 避免ThreadLocal内存泄漏
if (count <= 1) {
readHolds.remove();
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;
}
}
private void doReleaseShared() {
// 死循环
for (;;) {
// 获取头节点
Node h = head;
// 证明AQS队列有人排队
if (h != null && h != tail) {
// 获取头节点的状态
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;
}
}
扫一扫
153
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
