【JUC】并发编程 AQS，ReentryLock，CyclicBarrier，CountDownLatch 原理总结

AQS

AQS是什么？重写AQS就能实现锁的效果？

AQS是一个抽象类，是一个并发包的基础组件，用来实现各种锁，同步组件的工具（通过volatile + cas进行实现）。它包含了共享成员变量state、等待队列、条件队列、加锁线程并发中的核心组件。

共享成员变量state，不同实现中有不同含义。

等待队列，基于Node内部类，实现了一个双向链表。

条件队列，基于Node内部类，实现了一个单项链表，相当于Synchronized的wait和notify的一个等待唤醒机制的条件队列。

AQS自己继承了 AbstractOwnableSynchronizer，owner就是锁的持有者，对于线程信息的封装。

AQS还为我们自己实现锁和同步器采用模板方法模式，提供了一些模板方法。我们只需要根据自己的逻辑实现方法的重写，就可以实现各种不同的互斥/同步等效果。

例如：ReentrantLock 可重入锁的实现，阻塞加锁解锁等操作都是基于 ReentrantLock 内部的AQS组件实现的，本质上ReentrantLock只是提供了一系列相关的API。（Semaphore，CountDownLatch，CyclicBarrier，Renentrantreadwritelock，StampedLock）

AQS有两种模式：独占模式（ReentrantLock CycleBarrier）和共享模式（Semaphore CountDownLatch）

独占和共享的最大区别就是State的定义不同，独占模式下State只有0和1，共享资源/临界区代码只能由一个线程来执行，但是共享模式下的State可以为多个，只要是符合条件的当前线程都可以来使用。

补充： AQS的阻塞队列和条件队列的实现，都是通过Node节点，不过是通过Node节点的不同属性，且一个是双向一个是单向

在这里插入图片描述

阻塞队列双向的条件队列单向？

阻塞队列中被park( ) 的线程是需要由前继节点老unpark( ) 唤醒的。
- 当node加入到阻塞队列尾部，需要找到前一个节点，把它的waitStatus设置成 -1（表示它有责任唤醒后一个节点）
条件队列是由别的线程来signal( ) 唤醒的，且唤醒后会去阻塞队列中。
- 条件队列是FIFO，尾进头出的，不需要双向。

ReentryLock

在这里插入图片描述

lock，unlock

lock

加锁成功，将state改为1，设置owner为当前线程
加锁失败
1. 创建该线程对应的Node节点，并加入等待队列，此时waitStatus为0（默认值）
2. 会将加入队列的该线程调用Lock。unpark( ) 来阻塞，然后设置该节点的前驱节点的waitStatus为-1（用于后续unpark( ) 它）

unlock

加锁成功的线程要解锁后会unlock( ) 掉阻塞队列中第一个节点的线程，等待队列中出来的线程获取锁成功
1. setOwner为自己
2. 设置state为1
3. 更新等待队列
当unlock后，如果被unpark( ) 的线程获取锁失败，重新回到等待队列中，并park( ) 掉

锁重入

lock

第一次会正常加上锁，setOwner是自己，然后修改state为1。
第二次同一个线程又来加锁了，会检查到当前线程=owner线程，说明发生了锁重入现象。
然后会对state++，做一个累加操作，作为锁重入的计数。

unlock

state–；
只是一直对state–，并没有真正的释放锁，当state==0时，说明才真的该释放锁。
state==0 时再执行unlock方法流程。

可打断

ReentrantLock分为不可打断模式和可打断模式： lock.lock() 不可被打断 lock.lockInterruptibly(); 可被打断
使用时在API使用的不同选择的就是不同模式的加锁解锁方式

区别：

不可打断模式没有真的打断，只是设置打断标记为true。还是继续停留在等待队列中等待。当获取到锁之后才检查是否被打断，再进行打断。
可打断模式打断了，通过抛出异常的方式保证当前线程被打断。

公平，非公平

非公平锁（默认）和公平锁的主要区别在于 tryAcquire( ) 的实现。【尝试获取锁的方法】

当 state == 0 后的操作不同！

非公平锁一上来不会看等待队列中是否有阻塞等待的线程，而是直接去cas操作去判断state来竞争锁
公平锁一上来不会直接cas操作获取修改state，而是先判断等待队列中是否有优先级比我高的队列，实现了公平

相对来说，非公平锁会更好的性能，因为它的吞吐量比较大。

当然，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。

在这里插入图片描述

公平构造为 FairSync()

条件变量

每个条件变量其实对应着一个等待队列，其实现类是ConditionObject。

ConditionObject中维护了以Node为节点的双向链表所构成的队列。但是只使用了单向！

Await( )

首先获取到锁，然后条件不满足时调用await( ) 。
- 此时创建一个新的Node状态为 -2，并联这个不满足条件的线程，加入条件队列的尾部。
进入AQS的fullRelease，释放掉同步器上的锁。
1. 设置owner为null
2. setState = 0
3. unpark( ) 等待队列中的线程
去条件变量中等待的线程也会被park( ) 进入阻塞状态

Signal( )

（有一个节点的转移，会条件队列中获取队头元素转移到等待队列队尾，并重置waitStatus=0）

只有owner中的线程才有资格唤醒条件变量中的所有者！

取得在条件变量中（队首）的第一个Node
会将满足条件的该线程转移到等待队列中等待下次重新获取锁。
并将当前线程状态从-2改为0。因为等待队列中每次增加的元素都默认是0。

在这里插入图片描述

锁超时

public boolean tryLock()：尝试获取锁，获取到返回 true，获取不到直接放弃，不进入阻塞队列

public boolean tryLock(long timeout, TimeUnit unit)：在给定时间内获取锁，获取不到就退出

实现原理

成员变量：指定超时限制的阈值，小于该值的线程不会被挂起，会自旋
```
static final long spinForTimeoutThreshold = 1000L;
```
超时时间设置的小于该值，就会被禁止挂起，因为阻塞在唤醒的成本太高，不如选择自旋空转

tryLock()

sync.nonfairTryAcquire(1);// 只尝试一次

tryLock(long timeout, TimeUnit unit)

//先尝试一次nonfairTryAcquire()后

doAcquireNanos(arg, nanosTimeout);
// 获取最后期限的时间戳
// 计算还需等待的时间
// 时间已到     return false;
// 如果 nanosTimeout 大于该值，才有阻塞的意义，否则直接自旋会好点

ReentrantLock 对比 Synchronized

ReentrantLock 相对于 synchronized 具备如下特点：

锁的实现：synchronized 是 JVM 实现的，而 ReentrantLock 是 JDK 实现的
性能：新版本 Java 对 synchronized 进行了很多优化，synchronized 与 ReentrantLock 大致相同
使用：ReentrantLock 需要手动解锁，synchronized 执行完代码块自动解锁
可中断：ReentrantLock 可中断，而 synchronized 不行
公平锁：公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁
- ReentrantLock 可以设置公平锁，synchronized 中的锁是非公平的
- 不公平锁的含义是阻塞队列内公平，队列外非公平
锁超时：尝试获取锁，超时获取不到直接放弃，不进入阻塞队列
- ReentrantLock 可以设置超时时间，synchronized 会一直等待
锁绑定多个条件：一个 ReentrantLock 可以同时绑定多个 Condition 对象，更细粒度的唤醒线程
两者都是可重入锁

CyclicBarrier 对比 CountDownLatch

使用上的区别就是 CountDownLatch 的计数只能使用一次，CyclicBarrier在计数变为0之后，会重置计数！

等待主体不同。调用await( ) 方法的对象不同。
1. CountDownLatch是主线程调用await( ) 来等待其他线程将state减为0再来执行。阻塞的是主线程。
2. CyclicBarrier是工作线程调用await( ) ，await( ) 方法会对自身维护的计数器 -1 操作。阻塞的是工作线程。
  - 多组线程等待共同到达一个栅栏点，通过 signalAll( ) 一起出来，并且把 count 重新置为 parties。
CountDownLatch是通过AQS的State信号量来实现的，而CyclicBarrier是直接借助ReentrantLock加上Condition 等待唤醒的功能进而实现的。

在这里插入图片描述