线程并发基础知识点
什么是进程与线程
进程：正在进行的程序，进程作为资源分配的单位，在内存中会为每个进程分配不同的内存区域。
线程：是CPU调度的基本单位，每一个进程最少都有一个线程，每个线程执行的都是进程的代码中的某一片段
区别：
- 根本不同：进程是操作系统分配的资源，而线程是CPU调度的基本单位
- 资源方面：同一个进程下的线程，共享进程的一些资源，每个线程有自己的独立存储空间。进程之间的资源通常是相互独立的
- 通信方面：同一进程下不同的线程之间通信很方便，但是进程间的通信很麻烦
什么是多线程
多线程指的是单个进程中同时运行的多个进程
多线程的优点：
- 能够提高CPU的利用效率，进而提高用户的体验
多线程的局限性：
- 在线程特别多的情况下，CPU在执行切换上下文时，资源消耗大
- 多线程操作一个临界资源时，可能会出现数据不一致的情况，在牵扯到锁的情况下，甚至可能出现死锁的情况
什么是串行、并行与并发
串行：程序按照顺序一个一个执行
并行：程度同时处理多个任务
并发：并发是指CPU在极短时间内反复切换执行不同的线程
线程的创建方式
- 继承Thread类，重写run方法
- Java有单继承的局限性，所以不推荐使用
- 实现Runnable接口，重写run方法
- 没有返回值，不能够抛出异常，但是实现方式简单，且不受继承影响
- 实现Callable接口，重写call方法
- 优点：有返回值，可以抛出异常
- 缺点：线程创建比较麻烦，需要配合FutureTask 使用
线程的生命周期
同步/异步、阻塞/非阻塞
什么是同步：执行某个功能之后，被调用者不会主动通知你
什么是异步：执行某个功能之后，被调用者会主动通知你
什么是阻塞：执行某个功能之后，调用者需要一直等待结果
什么是非阻塞：执行某个功能之后，调用者不需要一直等待结果
什么是线程安全
当多个线程访问某一个类(对象或方法)时,对象对应的公共数据区始终都能表现正确,那么这个类(对象或方法)就是线程安全的。
并发编程三大特性
原子性
定义：一个操作不可分割，不可中断，一个线程在执行的时候，另一个线程不会影响到他
并发编程保证原子性：
-
synchronized
- synchronized是JVM层面的锁，可以使用synchronized关键字修饰方法，或者采用同步代码块的形式来确保原子性
-
CAS
-
所谓CAS就是Compare And Swap
-
CAS是CPU层面的并发语
-
再替换内存中的某个值时，他会先查看内存中的值是否与预期的值一致，如果一致，则执行替换操作
-
缺点：CAS只能保证一个变量的原子性，不能保证多行代码的原子性
-
问题：ABA问题
-
解决方案：为变量加一个版本属性
-
-
Lock
-
Lock锁是在JDK1.5由Doug Lea研发的，他的性能相比synchronized在JDK1.5的时期，性能好了很多多，但是在JDK1.6对synchronized优化之后，性能相差不大，但是如果涉及并发比较多时，推荐ReentrantLock锁，性能会更好。
-
ReentrantLock可以直接对比synchronized，在功能上来说，都是锁。
但是ReentrantLock的功能性相比synchronized更丰富。
ReentrantLock底层是基于AQS实现的，有一个基于CAS维护的state变量来实现锁的操作。
-
-
ThreadLocal
- 原理：同一线程只操作自己的临界变量，以此保证原子性
可见性
可见信问题出现在CPU层面，CPU的处理速度非常快，每次去主内存中获取值太慢了，所以CPU就提供了三级缓存。每个CPU厂商都有自己的MEIS协议，但是，当多个来自不同CPU的线程来访问同一资源时，可能会出现数据不一致的情况。Java作为一种跨平台的语言，当然是要有一套自己的规范，就是JMM。
问题出现的代码示例，再此代码中，t1、main两个线程就会得到不同的flag值
private static boolean flag = true;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (flag) {
// ....
}
System.out.println("t1线程结束");
});
t1.start();
Thread.sleep(10);
flag = false;
System.out.println("主线程将flag改为false");
}
解决方案
-
volatile关键字
-
被volatile修饰的变量，等同于告知CPU，在遇到这个变量时，不允许使用缓存中的变量值，必须要求去主内存中获取数据。
-
当volatile修饰的变量被写时，JMM会将当前线程修改之后的变量值，同步到主存中
-
当volatile修饰的变量被读时，JMM会将当前线程中的缓存区的变量值修改为无效，强制要求去主内存区域获取变量的值
-
原理是在被volatile修饰的变量在转为汇编语言之后，会带上一个lock前缀，当CPU遇到这个前缀之后会做两件事
- 将当前处理器缓存行的数据写回到主内存
- 这个写回的数据，在其他的CPU内核的缓存中，直接无效。
-
private volatile static boolean flag = true; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { while (flag) { // .... } System.out.println("t1线程结束"); }); t1.start(); Thread.sleep(10); flag = false; System.out.println("主线程将flag改为false"); }
-
-
synchronized关键字
-
如果遇到了synchronized修饰的代码块或者同步方法，在获取到锁资源之后，JMM会将涉及到的变量从缓存数据中移除，必须去主内存中重新拿数据，而且在释放锁之后，会立即将CPU缓存中的数据同步到主内存。
-
private static boolean flag = true; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { while (flag) { synchronized (MiTest.class){ //... } System.out.println(111); } System.out.println("t1线程结束"); }); t1.start(); Thread.sleep(10); flag = false; System.out.println("主线程将flag改为false"); }
-
-
Lock锁
-
Lock锁实现可见性是基于volatile实现的，Lock锁内部再进行加锁和释放锁时，会对一个由volatile修饰的state属性进行加减操作
-
volatile只会将它所修饰的变量同步到主内存中，而使用Lock之后，会将缓存中全部的属性都设置为无效，从缓存中重新获取
-
private static boolean flag = true; private static Lock lock = new ReentrantLock(); public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { while (flag) { lock.lock(); try{ //... }finally { lock.unlock(); } } System.out.println("t1线程结束"); }); t1.start(); Thread.sleep(10); flag = false; System.out.println("主线程将flag改为false"); }
-
有序性
CPU在执行指令的时候，回来提升执行效率，在满足一定情况下，CPU会对指令进行重排。Java中的程序时乱序是乱序执行的
private static volatile MiTest test;
private MiTest(){}
public static MiTest getInstance(){
// B
if(test == null){
synchronized (MiTest.class){
if(test == null){
// A , 开辟空间，test指向地址，初始化
test = new MiTest();
}
}
}
return test;
}
指令重排条件
-
as-if-serial
as-if-serial语义：
不论指定如何重排序，需要保证单线程的程序执行结果是不变的。
而且如果存在依赖的关系，那么也不可以做指令重排。
-
happens-before
具体规则：
1. 单线程happen-before原则：在同一个线程中，书写在前面的操作happen-before后面的操作。 2. 锁的happen-before原则：同一个锁的unlock操作happen-before此锁的lock操作。 3. volatile的happen-before原则： 对一个volatile变量的写操作happen-before对此变量的任意操作。 4. happen-before的传递性原则： 如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作。 5. 线程启动的happen-before原则：同一个线程的start方法happen-before此线程的其它方法。 6. 线程中断的happen-before原则：对线程interrupt方法的调用happen-before被中断线程的检测到中断发送的代码。 7. 线程终结的happen-before原则：线程中的所有操作都happen-before线程的终止检测。 8. 对象创建的happen-before原则：一个对象的初始化完成先于他的finalize方法调用。 **JMM只有在不出现上述8中情况时，才不会触发指令重排效果。** -
解决方案：使用volatile关键字
- 实现原理：内存屏障，会将两个操作之间添加一道指令，从而避免指令重排
Lock
锁的分类
可重入锁/不可重入锁
**可重入锁：**当前线程已经获取到了A锁，再次尝试获取A锁依旧可以获取的得到
**不可重入锁：**当前线程已经获取到了A锁，再次尝试获取A锁就不可以获取，需要等待自己释放锁才可以再次获取锁
Java中提供的synchronized、ReentrantLock、ReentrantReadWriteLock都是可重入锁
乐观锁/悲观锁
Java中提供的synchronized、ReentrantLock、ReentrantReadWriteLock都是悲观锁
CAS就是乐观锁
**悲观锁：**当获取不到锁资源时，会将当前线程挂起。而线程被挂起就会涉及到用户态和内核态的切换，这种切换很消耗资源
**用户态：**JVM可以自行执行的指令，不需要接触操作系统
**内核态：**JVM不可以自行执行的指令，需要操作系统执行才可以
**乐观锁：**当获取不到锁资源时，可以让CPU再次调度，重新尝试获取锁资源
公平锁/非公平锁
Java中提供的synchronized是非公平锁
Java中提供的ReentrantLock、ReentrantReadWriteLock可以实现公平锁，也可以实现公平锁
**公平锁：**当锁资源被A拿到之后，线程B来获取，发现被A占有，所以需要等待，此时C线程也获取资源，发现获取不到，所以排队在B线程之后，排队等待获取锁资源
**非公平锁：**当锁资源被A拿到之后，线程B来获取，发现被A占有，所以需要等待，此时C线程也获取资源，他会尝试去抢夺锁，如果抢到了，那就是抢到了，如果没抢到，那还是需要排队在B线程之后
互斥锁/共享锁
Java中提供的synchronized、ReentrantLock都是互斥锁
Java中提供的ReentrantReadWriteLock就是共享锁
**互斥锁：**同一时间只有一个线程可以占有锁
**共享锁：**同一时间可以有多个线程占有锁
深入synchronized
synchronized是基于对象实现的
类锁、对象锁
类锁：当使用synchronized修饰非静态方法时，就是类锁
对象锁：当使用synchronized修饰非静态方法时，就是对象锁
synchronized的优化
再JDK1.5 Doug Lee推出ReentrantLock之后，效率大大高于synchronized，所以在JDK1.6，就对synchronized做出了优化
锁消除：在synchronized修饰的代码中，如果不存在操作临界资源的情况，会触发锁消除，你即便写了synchronized，他也不会触发。
public synchronized void method(){
// 没有操作临界资源
// 此时这个方法的synchronized你可以认为木有~~
}
锁膨胀：如果在一个循环中，频繁的获取和释放做资源，这样带来的消耗很大，锁膨胀就是将锁的范围扩大，避免频繁的竞争和获取锁资源带来不必要的消耗。
public void method(){
for(int i = 0;i < 999999;i++){
synchronized(对象){
}
}
// 这是上面的代码会触发锁膨胀
synchronized(对象){
for(int i = 0;i < 999999;i++){
}
}
}
锁升级：ReentrantLock的实现，是先基于乐观锁的CAS尝试获取锁资源，如果拿不到锁资源，才会挂起线程。synchronized在JDK1.6之前，完全就是获取不到锁，立即挂起当前线程，所以synchronized性能比较差。
- 偏向锁：当前锁资源只有一个线程频繁获取时，那么只要这个线程过来，就会做一个判断
- 如果时当前线程，那么直接拿着锁走
- 如果不是当前线程，那么使用CAS的方式去尝试一次，如果获取不到，那就升级到轻量级锁
- 轻量级锁：会采用自旋锁的方式去频繁的以CAS的形式获取锁资源（采用的是自适应自旋锁）
- 如果获取到了锁，那么直接走
- 如果没获取到锁，在自旋一定次数时，那么直接升级
- 重量级锁
- 如果当前线程没有获取到锁资源，那么直接挂起
synchronized实现原理
synchronized是基于对象实现的。
先要对Java中对象在堆内存的存储有一个了解。
展开MarkWord
MarkWord中标记着四种锁的信息：无锁、偏向锁、轻量级锁
synchronized的锁升级
锁默认情况下，开启了偏向锁延迟。
偏向锁在升级为轻量级锁时，会涉及到偏向锁撤销，需要等到一个安全点（STW），才可以做偏向锁撤销，在明知道有并发情况，就可以选择不开启偏向锁，或者是设置偏向锁延迟开启
因为JVM在启动时，需要加载大量的.class文件到内存中，这个操作会涉及到synchronized的使用，为了避免出现偏向锁撤销操作，JVM启动初期，有一个延迟4s开启偏向锁的操作
如果正常开启偏向锁了，那么不会出现无锁状态，对象会直接变为匿名偏向
深入ReentrantLock
ReentrantLock与synchronized区别
- ReenstantLock是一个类，synchronized是关键字，两者都是在JVM层面上实现互斥锁
- 如果在竞争比较激烈的情况下，推荐使用ReenstrantLock去实现，ReenstrantLock不存在锁升级的过程，而synchronized只要升级到了重量级锁，就不可能再降级
- 底层实现也不同，ReenstrantLock是基于AQS实现的，而synchronized是基于ObjectMonitor实现的
- ReenstrantLock可以指定等待锁资源的时间
- ReenstrantLock支持公平锁和非公平锁，synchronized只支持公平锁
- synchronized使用完之后可以自动释放，ReenstrantLock需要手动释放
AQS概述
AQS是Java中的一个基类，全称AbstractQueuedSynchronizer，JUC下的很多内容都是基于AQS实现了部分功能，比如ReentrantLock，ThreadPoolExecutor，阻塞队列，CountDownLatch，Semaphore，CyclicBarrier等等都是基于AQS实现。
ReenstrantLock加锁流程
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,之前持有锁的线程释放了锁资源
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());
}
4、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;
}
}
}
}
5、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;
}
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方法（有参）
// 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
}
}
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();
}
ReenstrantLock释放锁流程
不管是公平锁还是非公平锁，都是使用unlock来释放锁的。
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);
}
AQS中为什么要有一个虚拟的head节点
AQS可以没有head，设计之初指定head只是为了更方便的操作。方便管理双向链表而已，一个哨兵节点的存在。
AQS中为什么使用双向链表
在执行tryLock，lockInterruptibly方法时，如果在线程阻塞时，中断了线程，此时线程会执行cancelAcquire取消当前节点，不在AQS的双向链表中排队。如果是单向链表，此时会导致取消节点，无法直接将当前节点的prev节点的next指针，指向当前节点的next节点。
深入ReenstrantReadWriteLock
为什么要有读写锁
synchronized和ReenstrantLock都是互斥锁，如果在读多写少的情境下，互斥锁的效率就有点低。但是涉及到写操作的情况下，还是需要互斥锁。
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();
}
}
读写锁的实现原理
ReenstrantReadWriteLock还是基于AQS实现的，内部还是对核心属性state进行操作，拿到锁资源就可以跑路，没有拿到锁资源依旧去AQS队列中排队
对于写锁：
- 写锁是针对state的低16位进行＋1操作
- 写锁是互斥锁，重入流程也就是跟ReenstrantLock大致相似，都是对state进行急＋1操作，但是读锁的可重入范围比ReenstrantLock小
对于读锁：
- 读锁是对state的高16为进行＋1操作
- 读锁是共享锁，对于所锁重入是可以有同时多个线程来获取的，我们通过ThreadLocal来记录读锁一共的重入次数
写锁饥饿问题：因为读锁是共享锁，如果现在有读锁已经占有锁资源，那么写锁再过来的话是获取不到锁资源的，他需要在AQS队列中排队等候，但是如果此时过来很多读锁请求，直接获取读锁资源的话，会导致锁一直被读锁占有，这就是写锁饥饿问题。
**解决方案：**如果现在读锁占用锁资源，且写锁已经在AQS队列中排队，那么后续来的读锁请求，都会将读锁线程丢到AQS队列中排队，后续抢占锁资源的话，只有在写锁之前的读锁请求能够获取读锁，在写锁之后的请求依旧排队
写锁获取锁流程
加锁流程：lock、acquire、tryAcquire、addWaiter、acquireQueued
// 写锁加锁的入口
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) {
// 当前没有线程持有写锁，读写互斥，告辞。
// 有线程持有写锁，持有写锁的线程不是当前线程，不是锁重入，告辞。
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 当前线程持有写锁。 锁重入。
if (w + exclusiveCount(acquires) > MAX_COUNT)
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;
}
// ================================================================
// 这个方法是将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
写锁释放锁流程
对于写锁的释放，大致的流程与ReenstarntLock差不多，唯一有点地方不同就是，tyrRelease中，写锁判断的是低16位是否为0。
释放流程为：unlock、Release、tryRelease、unparkSuccessor
// 写锁释放锁的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;
}
读锁加锁流程
比较复杂，大致流程：lock、acquireShared、tryacquireShared、readerShouldBlock（两种实现）、doAcquireShared
主要的获取锁函数为tryAcquireShared()方法
// 读锁加锁的方法入口
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)) {
// 省略部分代码！！！！
return 1;
}
return fullTryAcquireShared(current);
}
// 公平锁 与其他公平锁的实现类似
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t && // 说明没有节点在排队
((s = h.next) == null || s.thread != Thread.currentThread()); //说明有线程在排队，但是第一个排队的线程是我，那我可以抢夺锁资源
}
// 非公平锁的判断
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，可以直接抢占锁资源
}
读锁释放锁流程
unlock、releaseShared、tryReleaseShared、doReleaseShared
1、处理重入以及state的值
2、唤醒后续排队的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;
}
}
