第 3 章 JUC

谁借莪１个温暖的怀抱￠ 2022-10-29 09:21 204阅读 0赞

# 第 3 章 JUC #

## 1、题目说明 ##

> **1、Synchronized 相关问题**

1.  Synchronized 用过吗，其原理是什么？
2.  你刚才提到获取对象的锁，这个“锁”到底是什么？如何确定对象的锁
3.  什么是可重入性，为什么说Synchronized 是可重入锁？
4.  JVM对Java的原生锁做了哪些优化？
5.  为什么说Synchronized是非公平锁？
6.  什么是锁消除和锁粗化？
7.  为什么说Synchronized是一个悲观锁？乐观锁的实现原理又是什么？什么是CAS，它有什么优点和缺点？
8.  乐观锁一定就是好的吗？

> **2、可重入锁 ReentrantLock及其他显式锁相关问题**

1.  跟Synchronized相比，可重入锁ReentrantLock 其实现原理有什么不同？
2.  那么请谈谈AQS框架是怎么回事儿？
3.  请尽可能详尽地对比下Synchronized 和ReentrantLock的异同。
4.  ReentrantLock 是如何实现可重入性的？

## 2、可重入锁 ##

### 2.1、可重入锁概述 ###

> **可重入锁的概念**

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁(前提，锁对象得是同一个对象)，不会因为之前已经获取过还没释放而阻塞。

Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

### 2.2、可重入锁的字面解释 ###

> **可重入锁**

1.  可：可以。
2.  重：再次。
3.  入：进入
4.  锁：同步锁

--------------------

**进入什么？**

进入同步域（即同步代码块/方法或显式锁锁定的代码）

--------------------

**一句话说清楚**

一个线程中的多个流程可以获取同一把锁，持有这把同步锁可以再次进入。即自己可以获取自己的内部锁

### 2.3、可重入锁种类 ###

#### 2.3.1、隐式锁 ####

隐式锁（即synchronized关键字使用的锁）默认是可重入锁

> **1、同步代码块**

1.  代码
    
        /**
         * @ClassName ReEnterLockDemo
         * @Description 可重入锁:可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁，这样的锁就叫做可重入锁。
         * 在一个synchronized修饰的方法或代码块的内部调用本类的其他synchronized修饰的方法或代码块时，是永远可以得到锁的
         * @Author Oneby
         * @Date 2020/12/27 11:10
         * @Version 1.0
         */
        public class ReEnterLockDemo {
              
            
            // synchronized 同步代码块可重入演示
            static Object objectLockA = new Object();
        
            public static void m1() {
              
                new Thread(() -> {
              
                    synchronized (objectLockA) {
              
                        System.out.println(Thread.currentThread().getName() + "\t" + "------外层调用");
                        synchronized (objectLockA) {
              
                            System.out.println(Thread.currentThread().getName() + "\t" + "------中层调用");
                            synchronized (objectLockA) {
              
                                System.out.println(Thread.currentThread().getName() + "\t" + "------内层调用");
                            }
                        }
                    }
                }, "t1").start();
        
            }
        
            public static void main(String[] args) {
              
                m1();
            }
        }
2.  程序运行结果：在同一个线程内部成功获取同一把锁
    
    ![image-20201227111217931][]

> **2、同步方法**

1.  代码
    
        /**
         * @ClassName ReEnterLockDemo
         * @Description 可重入锁:可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁，这样的锁就叫做可重入锁。
         * 在一个synchronized修饰的方法或代码块的内部调用本类的其他synchronized修饰的方法或代码块时，是永远可以得到锁的
         * @Author Oneby
         * @Date 2020/12/27 11:10
         * @Version 1.0
         */
        public class ReEnterLockDemo {
              
            // synchronized 同步方法可重入演示
        
            public synchronized void m1() {
              
                System.out.println("=====外层");
                m2();
            }
        
            public synchronized void m2() {
              
                System.out.println("=====中层");
                m3();
            }
        
            public synchronized void m3() {
              
                System.out.println("=====内层");
            }
        
        
            public static void main(String[] args) {
              
                new ReEnterLockDemo().m1();
            }
        
        }
2.  程序运行结果
    
    ![image-20201227111606570][]

> **synchronized 原理**

1.  在 IDEA 终端中进入包名所在的文件夹
    
    ![image-20201227111932036][]
2.  使用 `javap -c xxx.class` 指令反编译字节码文件，可以看到有一对配对出现的 `monitorenter` 和 `monitorexit` 指令，一个对应于加锁，一个对应于解锁
    
    ![image-20201227112503639][]
3.  为什么会多出来一个 `monitorexit` 指令呢？
    
    如果同步代码块中出现Exception或者Error，则会调用第二个`monitorexit`指令来保证释放锁

--------------------

每个锁对象拥有一个锁计数器和一个指向持有该锁的线程的指针。

当执行`monitorenter`时，如果目标锋对象的计数器为零，那么说明它没有被其他线程所持有，Java虚拟机会将该锁对象的持有线程设置为当前线程，并且将其计数器加1。

在目标锁对象的计数器不为零的情况下，如果锁对象的持有线程是当前线程，那么Java虚拟机可以将其计数器加1，否则需要等待，直至持有线程释放该锁。

当执行`monitorexit`时，Java虚拟机则需将锁对象的计数器减1。计数器为零代表锁已被释放。

#### 2.3.2、显示锁 ####

显式锁（即Lock）也有ReentrantLock这样的可重入锁。

> **代码示例一：可重入演示**

1.  代码
    
        /**
         * @ClassName ReEnterLockDemo
         * @Description 可重入锁:可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁，这样的锁就叫做可重入锁。
         * 在一个synchronized修饰的方法或代码块的内部调用本类的其他synchronized修饰的方法或代码块时，是永远可以得到锁的
         * @Author Oneby
         * @Date 2020/12/27 11:10
         * @Version 1.0
         */
        public class ReEnterLockDemo {
              
            // ReentrantLock 可重入演示
            static Lock lock = new ReentrantLock();
        
            public static void main(String[] args) {
              
                new Thread(() -> {
              
                    lock.lock();
                    try {
              
                        System.out.println("=======外层");
                        lock.lock();
                        try {
              
                            System.out.println("=======内层");
                        } finally {
              
                            lock.unlock(); //正常情况，加锁几次就要解锁几次
                        }
                    } finally {
              
                        lock.unlock(); //正常情况，加锁几次就要解锁几次
                    }
                }, "t1").start();
                
            }
        
        }
2.  程序运行结果：在同一个线程内部成功获取同一把锁
    
    ![image-20201227113403872][]

> **代码示例二：加锁几次就要解锁几次**

**错误示例：**

1.  代码
    
        public class ReEnterLockDemo {
              
            // ReentrantLock 可重入演示
            static Lock lock = new ReentrantLock();
        
            public static void main(String[] args) {
              
                new Thread(() -> {
              
                    lock.lock();
                    try {
              
                        System.out.println("=======外层");
                        lock.lock();
                        try {
              
                            System.out.println("=======内层");
                        } finally {
              
                            lock.unlock();
                        }
                    } finally {
              
                        //实现加锁次数和释放次数不一样
                        //由于加锁次数和释放次数不一样，第二个线程始终无法获取到锁，导致一直在等待。
                        //lock.unlock();    //正常情况，加锁几次就要解锁几次
                    }
                }, "t1").start();
        
                new Thread(() -> {
              
                    lock.lock();
                    try {
              
                        System.out.println("b thread----外层调用lock");
                    } catch (Exception e) {
              
                        e.printStackTrace();
                    } finally {
              
                        lock.unlock();
                    }
                }, "t2").start();
            }
        
        }
2.  程序运行结果：执行到 t2 线程卡死，这是因为 t1 线程加了两次锁，但是之释放了一次锁，因此 t2 线程拿不到锁，程序无法正常结束
    
    ![image-20201227113651915][]

--------------------

**正确示例：**

1.  代码
    
        public class ReEnterLockDemo {
              
            // ReentrantLock 可重入演示
            static Lock lock = new ReentrantLock();
        
            public static void main(String[] args) {
              
                new Thread(() -> {
              
                    lock.lock();
                    try {
              
                        System.out.println("=======外层");
                        lock.lock();
                        try {
              
                            System.out.println("=======内层");
                        } finally {
              
                            lock.unlock();
                        }
                    } finally {
              
                        //实现加锁次数和释放次数不一样
                        //由于加锁次数和释放次数不一样，第二个线程始终无法获取到锁，导致一直在等待。
                        lock.unlock();    //正常情况，加锁几次就要解锁几次
                    }
                }, "t1").start();
        
                new Thread(() -> {
              
                    lock.lock();
                    try {
              
                        System.out.println("b thread----外层调用lock");
                    } catch (Exception e) {
              
                        e.printStackTrace();
                    } finally {
              
                        lock.unlock();
                    }
                }, "t2").start();
            }
        
        }
2.  程序运行结果：t1 线程加了两次锁，释放了两次锁，t2 线程可以拿到锁，等到 t2 线程执行完后，程序结束
    
    ![image-20201227113819079][]

## 3、LockSupport ##

### 3.1、LockSupport 是什么？ ###

> **LockSupport 是个什么鸡毛玩意儿？**

LockSupport是用来创建锁和其他同步类的基本线程阻塞原语。

LockSupport中的park()和unpark()的作用分别是阻塞线程和解除阻塞线程，可以将其看作是线程等待唤醒机制(wait/notify)的加强版

![image-20201227141842190][]

### 3.2、3种线程等待唤醒的方法 ###

> **3种让线程等待和唤醒的方法**

方式1: 使用Object中的wait()方法让线程等待， 使用Object中的notify()方法唤醒线程

方式2: 使用JUC包中Condition的await()方法让线程等待，使用signal()方法唤醒线程

方式3: LockSupport类可以阻塞当前线程以及唤醒指定被阻塞的线程

#### 3.2.1、Object 类 ####

Object类中的wait和notify方法实现线程等待和唤醒

> **1、正常情况：实现线程的等待和唤醒**

1.  代码
    
        static Object objectLock = new Object();
        
        private static void synchronizedWaitNotify() {
              
            new Thread(() -> {
              
                synchronized (objectLock) {
              
                    System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                    try {
              
                        objectLock.wait(); // 等待
                    } catch (InterruptedException e) {
              
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
                }
            }, "A").start();
        
            new Thread(() -> {
              
                synchronized (objectLock) {
              
                    objectLock.notify(); // 唤醒
                    System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
                }
            }, "B").start();
        }
2.  程序运行结果：A 线程先执行，执行 `objectLock.wait()` 后被阻塞，B 线程在 A 线程之后执行 `objectLock.notify()` 将 A线程唤醒
    
    ![image-20201227142853253][]

> **2、异常情况一：不在 synchronized 关键字中使用 wait() 和 notify() 方法**

1.  代码
    
        static Object objectLock = new Object();
        
        private static void synchronizedWaitNotify() {
              
            new Thread(() -> {
              
                //synchronized (objectLock) {
              
                System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                try {
              
                    objectLock.wait(); // 等待
                } catch (InterruptedException e) {
              
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
                //}
            }, "A").start();
        
            new Thread(() -> {
              
                //synchronized (objectLock) {
              
                objectLock.notify(); // 唤醒
                System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
                //}
            }, "B").start();
        }
2.  程序运行结果：不在 synchronized 关键字中使用 wait() 和 notify() 方法 ，将抛出 `java.lang.IllegalMonitorStateException` 异常
    
    ![image-20201227143041734][]

> **3、异常情况二：先 notify() 后 wait()**

1.  代码
    
        static Object objectLock = new Object();
        
        private static void synchronizedWaitNotify() {
              
            new Thread(() -> {
              
                try {
              
                    TimeUnit.SECONDS.sleep(3L);
                } catch (InterruptedException e) {
              
                    e.printStackTrace();
                }
                synchronized (objectLock) {
              
                    System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                    try {
              
                        objectLock.wait(); // 等待
                    } catch (InterruptedException e) {
              
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
                }
            }, "A").start();
        
            new Thread(() -> {
              
                synchronized (objectLock) {
              
                    objectLock.notify(); // 唤醒
                    System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
                }
            }, "B").start();
        }
2.  程序运行结果：B 线程先执行 `objectLock.notify()`，A 线程再执行 `objectLock.wait()`，这样 A 线程无法被唤醒
    
    ![image-20201227143523166][]

> **小总结**

wait和notify方法必须要在同步块或者方法里面且成对出现使用

先wait后notify才OK

#### 3.2.2、Condition接 口 ####

Condition接口中的await后signal方法实现线程的等待和唤醒

> **1、正常情况：实现线程的等待和唤醒**

1.  代码
    
        static Lock lock = new ReentrantLock();
        static Condition condition = lock.newCondition();
        
        private static void lockAwaitSignal() {
              
            new Thread(() -> {
              
                lock.lock();
                try {
              
                    System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                    try {
              
                        condition.await();
                    } catch (InterruptedException e) {
              
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
                } finally {
              
                    lock.unlock();
                }
            }, "A").start();
        
        
            new Thread(() -> {
              
                lock.lock();
                try {
              
                    condition.signal();
                    System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
                } finally {
              
                    lock.unlock();
                }
            }, "B").start();
        }
2.  程序运行结果：A 线程先执行，执行 `condition.await()` 后被阻塞，B 线程在 A 线程之后执行 `condition.signal()` 将 A线程唤醒
    
    ![image-20201227144235617][]

> **2、异常情况一：不在 lock() 和 unlock() 方法内使用 await() 和 signal() 方法**

1.  代码
    
        static Lock lock = new ReentrantLock();
        static Condition condition = lock.newCondition();
        
        private static void lockAwaitSignal() {
              
            new Thread(() -> {
              
                //lock.lock();
                try {
              
                    System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                    try {
              
                        condition.await();
                    } catch (InterruptedException e) {
              
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
                } finally {
              
                    //lock.unlock();
                }
            }, "A").start();
        
        
            new Thread(() -> {
              
                //lock.lock();
                try {
              
                    condition.signal();
                    System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
                } finally {
              
                    //lock.unlock();
                }
            }, "B").start();
        }
2.  程序运行结果：不在 lock() 和 unlock() 方法内使用 await() 和 signal() 方法，将抛出 `java.lang.IllegalMonitorStateException` 异常
    
    ![image-20201227144410693][]

> **3、异常情况二：先 signal() 后 await()**

1.  代码
    
        static Lock lock = new ReentrantLock();
        static Condition condition = lock.newCondition();
        
        private static void lockAwaitSignal() {
              
            new Thread(() -> {
              
                try {
              
                    TimeUnit.SECONDS.sleep(3L);
                } catch (InterruptedException e) {
              
                    e.printStackTrace();
                }
                lock.lock();
                try {
              
                    System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                    try {
              
                        condition.await();
                    } catch (InterruptedException e) {
              
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
                } finally {
              
                    lock.unlock();
                }
            }, "A").start();
        
        
            new Thread(() -> {
              
                lock.lock();
                try {
              
                    condition.signal();
                    System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
                } finally {
              
                    lock.unlock();
                }
            }, "B").start();
        }
2.  程序运行结果：B 线程先执行 `condition.signal()`，A 线程再执行 `condition.await()`，这样 A 线程无法被唤醒
    
    ![image-20201227144609959][]

> **传统的 synchronized 和 Lock 实现等待唤醒通知的约束**

线程先要获得并持有锁，必须在锁块（synchronized或lock）中

必须要先等待后唤醒，线程才能够被唤醒

#### 3.2.3、LockSupport 类 ####

> **通过 LockSupport 类实现线程的阻塞与唤醒~~~**

LockSupport类中的park等待和unpark唤醒，详细见下面讲解

### 3.3、LockSupport 类 ###

#### 3.3.1、LockSupport 是什么？ ####

> **官方文档解释**

LockSupport 是用来创建锁和其他同步类的基本线程阻塞原语。

LockSupport 类使用了一种名为 permit（许可）的概念来做到阻塞和唤醒线程的功能，每个线程都有一个许可（permit），permit 只有两个值 1 和零，默认是零。

可以把许可看成是一种（0, 1）信号量（Semaphore），但与 Semaphore 不同的是，许可的累加上限是 1。

![image-20201227145107546][]

#### 3.3.2、LockSupport 的主要方法 ####

> **1、主要方法**

![image-20201227145159471][]

> **2、阻塞**

`park()`/`park(Object blocker)`

`park()` 方法的作用：阻塞当前线程/阻塞传入的具体线程

permit 默认是 0，所以一开始调用 `park()` 方法，当前线程就会阻塞，直到别的线程将当前线程的 permit 设置为 1 时，`park()` 方法会被唤醒，然后会将 permit 再次设置为 0 并返回。

--------------------

park() 方法通过 Unsafe 类实现

// Disables the current thread for thread scheduling purposes unless the permit is available.
    public static void park() {
        
        UNSAFE.park(false, 0L);
    }

> **3、唤醒**

`unpark(Thread thread)`

`unpark()` 方法的作用：唤醒处于阻断状态的指定线程

调用 `unpark(thread)` 方法后，就会将 thread 线程的许可 permit 设置成 1（注意多次调用 `unpark()`方法，不会累加，permit 值还是 1），这会自动唤醒 thread 线程，即之前阻塞中的`LockSupport.park()`方法会立即返回。

--------------------

`unpark()` 方法通过 Unsafe 类实现

// Makes available the permit for the given thread
    public static void unpark(Thread thread) {
        
        if (thread != null)
            UNSAFE.unpark(thread);
    }

#### 3.3.3、LockSupport 代码示例 ####

> **1、正常使用 LockSupport**

1.  代码
    
        private static void lockSupportParkUnpark() {
              
            Thread a = new Thread(() -> {
              
                System.out.println(Thread.currentThread().getName() + "\t" + "------come in");
                LockSupport.park(); // 线程 A 阻塞
                System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒");
            }, "A");
            a.start();
        
            new Thread(() -> {
              
                LockSupport.unpark(a); // B 线程唤醒线程 A
                System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
            }, "B").start();
        }
2.  程序运行结果：A 线程先执行 `LockSupport.park()` 方法将通行证（permit）设置为 0，其实这并没有什么鸟用，因为 permit 初始值本来就为 0，然后 B 线程执行 `LockSupport.unpark(a)` 方法将 permit 设置为 1，此时 A 线程可以通行
    
    ![image-20201227150257575][]

> **2、先 unpark() 后 park()**

1.  代码
    
        private static void lockSupportParkUnpark() {
              
            Thread a = new Thread(() -> {
              
                try {
              
                    TimeUnit.SECONDS.sleep(3L);
                } catch (InterruptedException e) {
              
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread().getName() + "\t" + "------come in" + System.currentTimeMillis());
                LockSupport.park();
                System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒" + System.currentTimeMillis());
            }, "A");
            a.start();
        
            new Thread(() -> {
              
                LockSupport.unpark(a);
                System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
            }, "B").start();
        }
2.  程序运行结果：因为引入了通行证的概念，所以先唤醒（`unpark()`）其实并不会有什么影响，从程序运行结果可以看出，A 线程执行 `LockSupport.park()` 时并没有被阻塞
    
    ![image-20201227150548684][]

> **3、异常情况：没有考虑到 permit 上限值为 1**

1.  代码
    
        private static void lockSupportParkUnpark() {
              
            Thread a = new Thread(() -> {
              
                try {
              
                    TimeUnit.SECONDS.sleep(3L);
                } catch (InterruptedException e) {
              
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread().getName() + "\t" + "------come in" + System.currentTimeMillis());
                LockSupport.park();
                LockSupport.park();
                System.out.println(Thread.currentThread().getName() + "\t" + "------被唤醒" + System.currentTimeMillis());
            }, "A");
            a.start();
        
            new Thread(() -> {
              
                LockSupport.unpark(a);
                LockSupport.unpark(a);
                System.out.println(Thread.currentThread().getName() + "\t" + "------通知");
            }, "B").start();
        }
2.  程序运行结果：由于 permit 的上限值为 1，所以执行两次 `LockSupport.park()` 操作将导致 A 线程阻塞
    
    ![image-20201227151334553][]

> **LockSupport 小总结**

以前的两种方式：

以前的等待唤醒通知机制必须synchronized里面执行wait和notify，在lock里面执行await和signal，这上面这两个都必须要持有锁才能干

--------------------

LockSupport：俗称锁中断，LockSupport 解决了 synchronized 和 lock 的痛点

LockSupport不用持有锁块，不用加锁，程序性能好，无须注意唤醒和阻塞的先后顺序，不容易导致卡死

#### 3.3.4、LockSupport 重点说明 ####

> **1、LockSupport是用来创建锁和其他同步类的基本线程阻塞原语**

LockSupport是一个线程阻塞工具类，所有的方法都是静态方法，可以让线程在任意位置阻塞，阻塞之后也有对应的唤醒方法。归根结底，LockSupport调用的Unsafe中的native代码。

> **2、LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞的过程**

LockSupport和每个使用它的线程都有一个许可(permit)关联。permit相当于1，0的开关，默认是0，调用一次unpark就加1变成1，调用一次park会消费permit，也就是将1变成0，同时park立即返回。

如再次调用park会变成阻塞(因为permit为零了会阻塞在这里，一直到permit变为1)，这时调用unpark会把permit置为1。

每个线程都有一个相关的permit，permit最多只有一个，重复调用unpark也不会积累凭证。

> **3、形象的理解**

线程阻塞需要消耗凭证(permit)，这个凭证最多只有1个。

1.  当调用park方法时
    
    1.  如果有凭证，则会直接消耗掉这个凭证然后正常退出;
    2.  如果无凭证，就必须阻塞等待凭证可用;
2.  而unpark则相反，它会增加一个凭证，但凭证最多只能有1个，累加无效。

### 3.4、LockSupport 面试题 ###

> **为什么可以先唤醒线程后阻塞线程?**

因为unpark获得了一个凭证，之后再调用park方法，就可以名正言顺的凭证消费，故不会阻塞。

> **为什么唤醒两次后阻塞两次，但最终结果还会阻塞线程?**

因为凭证的数量最多为1，连续调用两次unpark和调用一次unpark效果一样，只会增加一个凭证；而调用两次park却需要消费两个凭证，证不够，不能放行。

## 4、AbstractQueuedSynchronizer ##

AbstractQueuedSynchronizer之AQS：抽象的队列同步器

### 4.1、AQS 前置知识 ###

> **前置知识**

1.  公平锁和非公平锁
2.  可重入锁
3.  LockSupport
4.  自旋锁
5.  数据结构之链表
6.  设计模式之模板设计模式

### 4.2、AQS 是什么？ ###

> **1、字面意思**

AQS（AbstractQueuedSynchronizer）：抽象的队列同步器

--------------------

一般我们说的 AQS 指的是 `java.util.concurrent.locks` 包下的 AbstractQueuedSynchronizer，但其实还有另外三种抽象队列同步器：`AbstractOwnableSynchronizer`、`AbstractQueuedLongSynchronizer` 和 `AbstractQueuedSynchronizer`

![image-20201227165511298][]

> **2、技术翻译**

AQS 是用来构建锁或者其它同步器组件的重量级基础框架及整个JUC体系的基石， 通过内置的FIFO队列来完成资源获取线程的排队工作，并通过一个int类变量（state）表示持有锁的状态

CLH：Craig、Landin and Hagersten 队列，是一个双向链表，AQS中的队列是CLH变体的虚拟双向队列FIFO

![image-20201227165645081][]

### 4.3、AQS 是 JUC 的基石 ###

> **和AQS有关的并发编程类**

![image-20201227165833625][]

> **举几个常见的例子**

1.  ReentrantLock
    
    ![image-20201227170144582][]
2.  CountDownLatch
    
    ![image-20201227170206077][]
3.  ReentrantReadWriteLock
    
    ![image-20201227170259365][]
4.  Semaphore
    
    ![image-20201227170320393][]
5.  …

> **进一步理解锁和同步器的关系**

锁，面向锁的使用者。定义了程序员和锁交互的使用层API，隐藏了实现细节，你调用即可，可以理解为用户层面的 API。

同步器，面向锁的实现者。比如Java并发大神Douglee，提出统一规范并简化了锁的实现，屏蔽了同步状态管理、阻塞线程排队和通知、唤醒机制等，Java 中有那么多的锁，就能简化锁的实现啦。

### 4.4、AQS 能干嘛 ###

> **AQS：加锁会导致阻塞**

有阻塞就需要排队，实现排队必然需要有某种形式的队列来进行管理

抢到资源的线程直接使用办理业务，抢占不到资源的线程的必然涉及一种排队等候机制，抢占资源失败的线程继续去等待（类似办理窗口都满了，暂时没有受理窗口的顾客只能去候客区排队等候），仍然保留获取锁的可能且获取锁流程仍在继续（候客区的顾客也在等着叫号，轮到了再去受理窗口办理业务）。

既然说到了排队等候机制，那么就一定 会有某种队列形成，这样的队列是什么数据结构呢？如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是CLH队列的变体实现的，将暂时获取不到锁的线程加入到队列中，这个队列就是AQS的抽象表现。它将请求共享资源的线程封装成队列的结点（Node） ，通过CAS、自旋以及LockSuport.park()的方式，维护state变量的状态，使并发达到同步的效果。

![image-20201227165645081][image-20201227165645081 1]

### 4.5、AQS 初步认识 ###

> **1、AQS初识**

官网解释

![image-20201227171157475][]

--------------------

有阻塞就需要排队，实现排队必然需要队列

1.  AQS使用一个volatile的int类型的成员变量来表示同步状态，通过内置的 FIFO队列来完成资源获取的排队工作将每条要去抢占资源的线程封装成 一个Node节点来实现锁的分配，通过CAS完成对State值的修改。
2.  Node 节点是啥？答：你有见过 HashMap 的 Node 节点吗？JDK 用 `static class Node<K,V> implements Map.Entry<K,V> {` 来封装我们传入的 KV 键值对。这里也是一样的道理，JDK 使用 Node 来封装（管理）Thread
3.  可以将 Node 和 Thread 类比于候客区的椅子和等待用餐的顾客

![image-20201227171739495][]

> **2、AQS内部体系架构**

0、AQS 内部体系框架

![image-20201227182248032][]

--------------------

1、AQS的int变量

AQS的同步状态State成员变量，类似于银行办理业务的受理窗口状态：零就是没人，自由状态可以办理；大于等于1，有人占用窗口，等着去

/**
     * The synchronization state.
     */
    private volatile int state;

--------------------

2、AQS的CLH队列

CLH队列（三个大牛的名字组成），为一个双向队列，类似于银行侯客区的等待顾客

![image-20201227180550246][]

--------------------

3、内部类Node（Node类在AQS类内部）

Node的等待状态waitState成员变量，类似于等候区其它顾客(其它线程)的等待状态，队列中每个排队的个体就是一个Node

/**
     * Status field, taking on only the values:
     *   SIGNAL:     The successor of this node is (or will soon be)
     *               blocked (via park), so the current node must
     *               unpark its successor when it releases or
     *               cancels. To avoid races, acquire methods must
     *               first indicate they need a signal,
     *               then retry the atomic acquire, and then,
     *               on failure, block.
     *   CANCELLED:  This node is cancelled due to timeout or interrupt.
     *               Nodes never leave this state. In particular,
     *               a thread with cancelled node never again blocks.
     *   CONDITION:  This node is currently on a condition queue.
     *               It will not be used as a sync queue node
     *               until transferred, at which time the status
     *               will be set to 0. (Use of this value here has
     *               nothing to do with the other uses of the
     *               field, but simplifies mechanics.)
     *   PROPAGATE:  A releaseShared should be propagated to other
     *               nodes. This is set (for head node only) in
     *               doReleaseShared to ensure propagation
     *               continues, even if other operations have
     *               since intervened.
     *   0:          None of the above
     *
     * The values are arranged numerically to simplify use.
     * Non-negative values mean that a node doesn't need to
     * signal. So, most code doesn't need to check for particular
     * values, just for sign.
     *
     * The field is initialized to 0 for normal sync nodes, and
     * CONDITION for condition nodes.  It is modified using CAS
     * (or when possible, unconditional volatile writes).
     */
    volatile int waitStatus;

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;
        
        //等待condition唤醒
        static final int CONDITION = -2;
        
        //共享式同步状态获取将会无条件地传播下去
        static final int PROPAGATE = -3;
        
        // 初始为e，状态是上面的几种
        volatile int waitStatus;
        
        // 前置节点
        volatile Node prev;
        
        // 后继节点
        volatile Node next;
    
        // ...

--------------------

4、总结

有阻塞就需要排队，实现排队必然需要队列，通过state 变量 + CLH双端 Node 队列实现

> **3、AQS同步队列的基本结构**

![image-20201227181324215][]

> **4、AQS底层是怎么排队的？**

通过调用 `LockSupport.pork()` 来进行排队

### 4.6、从 ReentrantLock 进入 SQS ###

#### 4.6.1、ReentrantLock 锁 ####

> **ReentrantLock 锁是个啥玩意儿？**

`ReentrantLock` 类是 `Lock` 接口的实现类，基本都是通过【聚合】了一个【队列同步器】的子类完成线程访问控制的

> **ReentrantLock 的原理**

`ReentrantLock` 实现了 Lock 接口，在 `ReentrantLock` 内部聚合了一个 `AbstractQueuedSynchronizer` 的实现类

![image-20210120232821132][]

#### 4.6.2、公平锁 & 非公平锁 ####

> **通过 `ReentrantLock` 的源码来讲解公平锁和非公平锁**

在 `ReentrantLock` 内定义了静态内部类，分别为 `NoFairSync`（非公平锁）和 `FairSync`（公平锁）

![image-20210120233544105][]

`ReentrantLock` 的构造函数：不传参数表示创建非公平锁；参数为 true 表示创建公平锁；参数为 false 表示创建非公平锁![image-20210120233844339][]

捞一眼 `lock()` 方法的执行流程：以 `NonfairSync` 为例

![image-20210121111748695][]

在 `ReentrantLock` 中，`NoFairSync` 和 `FairSync` 中 `tryAcquire()` 方法的区别，可以明显看出公平锁与非公平锁的`lock()`方法唯一的区别就在于公平锁在获取同步状态时多了一个限制条件:  
`hasQueuedPredecessors()`

![image-20210121000608878][]

`hasQueuedPredecessors()` 方法是公平锁加锁时判断等待队列中是否存在有效节点的方法

![image-20210121001224590][]

> **公平锁与非公平锁的总结**

对比公平锁和非公平锁的`tryAcqure()`方法的实现代码， 其实差别就在于非公平锁获取锁时比公平锁中少了一个判断`!hasQueuedPredecessors()`，`hasQueuedPredecessors()`中判断了是否需要排队，导致公平锁和非公平锁的差异如下:

1.  公平锁：公平锁讲究先来先到，线程在获取锁时，如果这个锁的等待队列中已经有线程在等待，那么当前线程就会进入等待队列中；
2.  非公平锁：不管是否有等待队列，如果可以获取锁，则立刻占有锁对象。也就是说队列的第一 个排队线程在`unpark()`，之后还是需要竞争锁(存在线程竞争的情况下)

![image-20210121001449731][]

而 `acquire()` 方法最终都会调用 `tryAcquire()` 方法

![image-20210121001548115][]

在 `NonfairSync` 和 `FairSync` 中均重写了其父类 `AbstractQueuedSynchronizer` 中的 `tryAcquire()` 方法

![image-20210121111707355][]

#### 4.6.3、从非公平锁的 lock() 入手 ####

> **先从示例代码入手**

源码解读比较困难，我们这里举个栗子，假设 A、B、C 三个人都要去银行窗口办理业务，但是银行窗口只有一个个，我们使用 `lock.lock()` 模拟这种情况

/**
     * @ClassName AQSDemo
     * @Description TODO
     * @Author Oneby
     * @Date 2021/1/21 11:08
     * @Version 1.0
     */
    public class AQSDemo {
        
        public static void main(String[] args) {
        
    
            ReentrantLock lock = new ReentrantLock();
    
            // 带入一个银行办理业务的案例来模拟我们的AQS如何进行线程的管理和通知唤醒机制
            // 3个线程模拟3个来银行网点，受理窗口办理业务的顾客
            // A顾客就是第一个顾客，此时受理窗口没有任何人，A可以直接去办理
            new Thread(() -> {
        
                lock.lock();
                try {
        
                    System.out.println("-----A thread come in");
                    try {
        
                        TimeUnit.MINUTES.sleep(20);
                    } catch (Exception e) {
        
                        e.printStackTrace();
                    }
                } finally {
        
                    lock.unlock();
                }
            }, "A").start();
    
            // 第二个顾客，第二个线程---》由于受理业务的窗口只有一个(只能一个线程持有锁)，此时B只能等待，
            // 进入候客区
            new Thread(() -> {
        
                lock.lock();
                try {
        
                    System.out.println("-----B thread come in");
                } finally {
        
                    lock.unlock();
                }
            }, "B").start();
    
            // 第三个顾客，第三个线程---》由于受理业务的窗口只有一个(只能一个线程持有锁)，此时C只能等待，
            // 进入候客区
            new Thread(() -> {
        
                lock.lock();
                try {
        
                    System.out.println("-----C thread come in");
                } finally {
        
                    lock.unlock();
                }
            }, "C").start();
        }
    }

> **先来看看线程 A（客户 A）的执行流程**

之前已经讲到过，`new ReentrantLock()` 不传参默认是非公平锁，调用 `lock.lock()` 方法最终都会执行 `NonfairSync` 重写后的 `lock()` 方法

**第一次执行 lock() 方法**

由于第一次执行 `lock()` 方法，`state` 变量的值等于 0，表示 lock 锁没有被占用，此时执行 `compareAndSetState(0, 1)` CAS 判断，可得 `state == expected == 0`，因此 CAS 成功，将 `state` 的值修改为 1

![image-20210121111228162][]

再来复习下 CAS：通过 `Unsafe` 提供的 `compareAndSwapXxx()` 方法保证修改操作的原子性（通过 CPU 原语保证），如果变量的值等于期望值，则修改变量的值为 `update`，并返回 `true`；若不等，则返回 `false`。`this` 代表当前对象，`stateOffset` 表示 `state` 变量在该对象中的偏移量

![image-20210121112329193][]

再来看看 `setExclusiveOwnerThread()` 方法做了啥：将拥有 lock 锁的线程修改为线程 A

![image-20210121112536036][]

> **再来看看线程 B（客户 B）的执行流程**

**第二次执行 lock() 方法**

由于第二次执行 `lock()` 方法，`state` 变量的值等于 1，表示 lock 锁没有被占用，此时执行 `compareAndSetState(0, 1)` CAS 判断，可得 `state != expected`，因此 CAS 失败，进入 `acquire()` 方法

![image-20210121113955304][]

`acquire()` 方法主要包含如下几个方法，下面我们一个一个来讲解

![image-20210121114219194][]

--------------------

**`tryAcquire(arg)` 方法的执行流程**

先来看看 `tryAcquire()` 方法，诶，怎么抛了个异常？别着急，仔细一看是 `AbstractQueuedSynchronizer` 抽象队列同步器中定义的方法，既然抛出了异常，就证明父类强制要求子类去实现

![image-20210121114934243][]

Ctrl + Alt + B 找到子类中的实现

![image-20210121115330658][]

这里以非公平锁 `NonfairSync` 为例，在 `tryAcquire()` 方法中调用了 `nonfairTryAcquire()` 方法，注意，这里传入的参数都是 1

![image-20210121115401635][]

--------------------

**`nonfairTryAcquire(acquires)` 正常的执行流程：**

在 `nonfairTryAcquire()` 方法中，大多数情况都是如下的执行流程：线程 B 执行 `int c = getState()` 时，获取到 `state` 变量的值为 1，表示 lock 锁正在被占用；于是执行 `if (c == 0) {` 发现条件不成立，接着执行下一个判断条件 `else if (current == getExclusiveOwnerThread()) {`，`current` 线程为线程 B，而 `getExclusiveOwnerThread()` 方法返回正在占用 lock 锁的线程，为线程 A，因此 `tryAcquire()` 方法最后会 `return false`，表示并没有抢占到 lock 锁

![image-20210121115655181][]

**补充**：`getExclusiveOwnerThread()` 方法返回正在占用 lock 锁的线程（排他锁，exclusive）

![image-20210121184512310][]

--------------------

**`nonfairTryAcquire(acquires)` 比较特殊的执行流程：**

第一种情况是，走到 `int c = getState()` 语句时，此时线程 A 恰好执行完成，让出了 lock 锁，那么 `state` 变量的值为 0，当然发生这种情况的概率很小，那么线程 B 执行 CAS 操作成功后，将占用 lock 锁的线程修改为自己，然后返回 `true`，表示抢占锁成功。其实这里还有一种情况，需要留到 `unlock()` 方法才能说清楚

第二种情况为可重入锁的表现，假设 A 线程又再次抢占 lock 锁（当然示例代码里面并没有体现出来），这时 `current == getExclusiveOwnerThread()` 条件成立，将 `state` 变量的值加上 `acquire`，这种情况下也应该 `return true`，表示线程 A 正在占用 lock 锁。因此，`state` 变量的值是可以大于 1 的

![image-20210121115807635][]

> **继续往下走，执行 `ddWaiter(Node.EXCLUSIVE)` 方法**

在 `tryAcquire()` 方法返回 `false` 之后，进行 `!` 操作后为 `true`，那么会继续执行 `addWaiter()` 方法

![image-20210121190805007][]

--------------------

**来看看 `addWaiter()` 方法做了些啥？**

之前讲过，`Node` 节点用于封装用户线程，这里将当前正在执行的线程通过 `Node` 封装起来（当前线程正是抢占 lock 锁没有抢占到的线程）

判断 tail 尾指针是否为空，双端队列此时还没有元素呢~肯定为空呀，那么执行 `enq(node)` 方法，将封装了线程 B 的 `Node` 节点入队

![image-20210121191412693][]

--------------------

**enq(node) 方法：构建双端同步队列**

也许看到这里的代码有点蒙，需要有些前置知识，在双端同步队列中，第一个节点为虚节点（也叫哨兵节点），其实并不存储任何信息，只是占位。 真正的第一个有数据的节点，是从第二个节点开始的。

![image-20210121204334235][]

**第一次执行 for 循环**：现在解释起来就不费劲了，当线程 B 进来时，双端同步队列为空，此时肯定要先构建一个哨兵节点。此时 `tail == null`，因此进入 `if(t == null) {` 的分支，头指针指向哨兵节点，此时队列中只有一个节点，尾节点即是头结点，因此尾指针也指向该哨兵节点

![image-20210121204517530][]

**第二次执行 for 循环**：现在该将装着线程 B 的节点放入双端同步队列中，此时 `tail` 指向了哨兵节点，并不等于 `null`，因此 `if (t == null)` 不成立，进入 `else` 分支。以尾插法的方式，先将 `node`（装着线程 B 的节点）的 `prev` 指向之前的 `tail`，再将 node 设置为尾节点（执行 `compareAndSetTail(t, node)`），最后将 `t.next` 指向 `node`，最后执行 `return t`结束 for 循环

![image-20210121204530559][]

**补充**：`compareAndSetTail(t, node)` 方法的实现

![image-20210121205727448][]

**注意**：哨兵节点和 `nodeB` 节点的 `waitStatus` 均为 0，表示在等待队列中

--------------------

**`acquireQueued()` 方法的执行**

执行完 `addWaiter()` 方法之后，就该执行 `acquireQueued()` 方法了，这个方法有点东西，我们放到后面再去讲它

![image-20210121211710519][]

> **最后来看看线程 C（客户 C）的执行流程**

线程 C 和线程 B 的执行流程很类似，都是执行 `acquire()` 中的方法

![image-20210121212144368][]

但是在 `addWaiter()` 方法中，执行流程有些区别。此时 `tail != null`，因此在 `addWaiter()` 方法中就已经将 `nodeC` 添加至队尾了

![image-20210121212702577][]

执行完 `addWaiter()` 方法后，就已经将 nodeC 挂在了双端同步队列的队尾，不需要再执行 `enq(node)` 方法

![image-20210121212502988][]

> **补前面的坑：`acquireQueued()` 方法的执行逻辑**

先来看看看看 `acquireQueued()` 方法的源代码，其实这样直接看代码有点懵逼，我们接下来举例来理解。注意看：两个 `if` 判断中的代码都放在 `for( ; ; )` 中执行，这样可以实现自旋的操作

![image-20210121222550561][]

--------------------

**线程 B 的执行流程**

线程 B 执行 `addWaiter()` 方法之后，就进入了 `acquireQueued()` 方法中，此时传入的参数为封装了线程 B 的 `nodeB` 节点，`nodeB` 的前驱结点为哨兵节点，因此 `final Node p = node.predecessor()` 执行完后，`p` 将指向哨兵节点。哨兵节点满足 `p == head`，但是线程 B 执行 `tryAcquire(arg)` 方法尝试抢占 lock 锁时还是会失败，因此会执行下面 `if` 判断中的 `shouldParkAfterFailedAcquire(p, node)` 方法，该方法的代码如下：

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
            /*
             * This node has already set status asking a release
             * to signal it, so it can safely park.
             */
            return true;
        if (ws > 0) {
        
            /*
             * Predecessor was cancelled. Skip over predecessors and
             * indicate retry.
             */
            do {
        
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
        
            /*
             * waitStatus must be 0 or PROPAGATE.  Indicate that we
             * need a signal, but don't park yet.  Caller will need to
             * retry to make sure it cannot acquire before parking.
             */
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

哨兵节点的 `waitStatus == 0`，因此执行 CAS 操作将哨兵节点的 `waitStatus` 改为 `Node.SIGNAL(-1)`

![image-20210121223354921][]

**注意**：`compareAndSetWaitStatus(pred, ws, Node.SIGNAL)` 调用 `unsafe.compareAndSwapInt(node, waitStatusOffset, expect, update);` 实现，虽然 `compareAndSwapInt()` 方法内无自旋，但是在 `acquireQueued()` 方法中的 `for( ; ; )` 能保证此自选操作成功（另一种情况就是线程 B 抢占到 lock 锁）

![image-20210121223722445][]

执行完上述操作，将哨兵节点的 `waitStatus` 设置为了 -1

![image-20210121225757259][]

执行完毕将退出 `if` 判断，又会重新进入 `for( ; ; )` 循环，此时执行 `shouldParkAfterFailedAcquire(p, node)` 方法时会返回 `true`，因此此时会接着执行 `parkAndCheckInterrupt()` 方法

![image-20210121224051493][]

线程 B 调用 `park()` 方法后被挂起，程序不会然续向下执行，程序就在这儿排队等待

![image-20210121224352912][]

--------------------

**线程 C 的执行流程**

线程 C 最终也会执行到 `LockSupport.park(this);` 处，然后被挂起，进入等待区

--------------------

**总结**：

如果前驱节点的 `waitstatus` 是 `SIGNAL` 状态（-1），即 `shouldParkAfterFailedAcquire()` 方法会返回 `true`，程序会继续向下执行 `parkAndCheckInterrupt()` 方法，用于将当前线程挂起

根据 `park()` 方法 API 描述，程序在下面三种情况会继续向下执行：

1.  被 unpark
2.  被中断（interrupt）
3.  其他不合逻辑的返回才会然续向下执行

因上述三种情况程序执行至此，返回当前线程的中断状态，并清空中断状态。如果程序由于被中断，该方法会返回 true

#### 4.6.4、可总算要 unlock() 了 ####

> **线程 A 执行 `unlock()` 方法**

A 线程终于要 `unlock()` 了吗？真不容易啊！

![image-20210121232036272][]

`unlock()` 方法调用了 `sync.release(1)` 方法

![image-20210121232105858][]

--------------------

**`release()` 方法的执行流程**

其实主要就是看看 `tryRelease(arg)` 方法和 `unparkSuccessor(h)` 方法的执行流程，这里先大概说以下，能有个印象：线程 A 即将让出 lock 锁，因此 `tryRelease()` 执行后将返回 `true`，表示礼让成功，`head` 指针指向哨兵节点，并且 `if` 条件满足，可执行 `unparkSuccessor(h)` 方法

![image-20210121232208076][]

--------------------

**`tryRelease(arg)` 方法的执行逻辑**

又是 `AbstractQueuedSynchronizer` 类中定义的方法，又是抛了个异常

![image-20210121232455853][]

老样子 Ctrl + Alt + B，查看其具体实现

![image-20210121232611915][]

线程 A 只加锁过一次，因此 `state` 的值为 1，参数 `release` 的值也为 1，因此 `c == 0`。将 `free` 设置为 `true`，表示当前 lock 锁已被释放，将排他锁占有的线程设置为 `null`，表示没有任何线程占用 lock 锁

![image-20210121232831741][]

--------------------

**`unparkSuccessor(h)` 方法的执行逻辑**

在 `release()` 方法中获取到的头结点 `h` 为哨兵节点，`h.waitStatus == -1`，因此执行 CAS操作将哨兵节点的 `waitStatus` 设置为 0，并将哨兵节点的下一个节点（`s = node.next = nodeB`）获取出来，并唤醒 `nodeB` 中封装的线程（`if (s == null || s.waitStatus > 0)` 不成立，只有 `if (s != null)` 成立）

![image-20210121233243604][]

--------------------

执行完上述操作后，当前占用 lock 锁的线程为 `null`，哨兵节点的 `waitStatus` 设置为 0，`state` 的值为 0（表示当前没有任何线程占用 lock 锁）

![image-20210121234116600][]

> **杀个回马枪：继续来看 B 线程被唤醒之后的执行逻辑**

再次回到 `lock()` 方法的执行流程中来，线程 B 被 `unpark()` 之后将不再阻塞，继续执行下面的程序，线程 B 正常被唤醒，因此 `Thread.interrupted()` 的值为 `false`，表示线程 B 未被中断

![image-20210121234331407][]

回到上一层方法中，此时 lock 锁未被占用，线程 B 执行 `tryAcquire(arg)` 方法能够抢到 lock 锁，并且将 `state` 变量的值设置为 1，表示该 lock 锁已经被占用

![image-20210121234645513][]

接着来研究下 `setHead(node)` 方法：传入的节点为 `nodeB`，头指针指向 `nodeB` 节点；将 `nodeB` 中封装的线程置为 `null`（因为已经获得锁了）；`nodeB` 不再指向其前驱节点（哨兵节点）。这一切都是为了将 `nodeB` 作为新的哨兵节点

![image-20210121234848286][]

执行完 `setHead(node)` 方法的状态如下图所示

![image-20210121235010086][]

将 `p.next` 设置为 `null`，这是原来的哨兵节点就是完全孤立的一个节点，此时 `nodeB` 作为新的哨兵节点

![image-20210121235357538][]

哇哦，通透，线程 C 也是类似的执行流程

### 4.7、AQS 总结 ###

> **AQS 的考点**

**第一个考点**：我相信你应该看过源码了，那么AQS里面有个变量叫State，它的值有几种？

**答**：3个状态：没占用是0，占用了是1，大于1是可重入锁

--------------------

**第二个考点**：如果锁正在被占用，AB两个线程进来了以后，请问这个总共有多少个Node节点？

**答**：答案是3个，分别是哨兵节点、nodeA、nodeB

--------------------

> **AQS 源码解读案例图示**

![image-20210122101219469][]

[image-20201227111217931]: /images/20221024/dc7257002a364431abbae59099f6f1d3.png
[image-20201227111606570]: /images/20221024/3213359b4efb47f8a2b305dca678e785.png
[image-20201227111932036]: /images/20221024/c439bfc817f74458bbad151f760895e8.png
[image-20201227112503639]: /images/20221024/be1d77bf58414583b0955bbbe1c9ee91.png
[image-20201227113403872]: /images/20221024/9b6c18559de54477842ccded137f8b65.png
[image-20201227113651915]: /images/20221024/e6cb38b70dc448c7902bb51790f1a1e5.png
[image-20201227113819079]: /images/20221024/eb16be4bff2540c8a074cee6e1a2d8db.png
[image-20201227141842190]: /images/20221024/5bc46dd0977848379e93d258dabf9cc0.png
[image-20201227142853253]: /images/20221024/88b91723f783494c95acbcdb160fecdb.png
[image-20201227143041734]: /images/20221024/6ef2e605470840c191498f899d4cb64a.png
[image-20201227143523166]: /images/20221024/d74a754961e641609f3d354d4b09fec2.png
[image-20201227144235617]: /images/20221024/a97bedc91bc04f4cb7f57c50b98b8d11.png
[image-20201227144410693]: /images/20221024/0ab2b02c4da24c7baefe3751883b7962.png
[image-20201227144609959]: /images/20221024/dcb6ee06e4f14ec3a06e9ffdffc47937.png
[image-20201227145107546]: /images/20221024/8dfba8ce603c44c4a504898e1a86b706.png
[image-20201227145159471]: /images/20221024/4e56db74f1e54400b5480ac9391d185a.png
[image-20201227150257575]: /images/20221024/352e5b3b93cc4c98bdc044b3d7bc1c43.png
[image-20201227150548684]: /images/20221024/54ee3d8e1ef7408bb1bf880441092e40.png
[image-20201227151334553]: /images/20221024/5941a53c804a4281bc043e1235cc74b9.png
[image-20201227165511298]: /images/20221024/0c1c4c7a170b4116bc8bad3ac21913b4.png
[image-20201227165645081]: /images/20221024/a096aaf3fe6c47019331724bb760e301.png
[image-20201227165833625]: /images/20221024/edd5f29e90f147638062488dbf18685f.png
[image-20201227170144582]: /images/20221024/57c66a228bc9449898e0598db332a855.png
[image-20201227170206077]: /images/20221024/8f3516edd02e4c4681412228474220a5.png
[image-20201227170259365]: /images/20221024/a8f0b2fa029e49c2be6b1749df599541.png
[image-20201227170320393]: /images/20221024/4cce94e9730e4143b898e3008f870b90.png
[image-20201227165645081 1]: /images/20221024/e516be4135944c1ca16169f7d22b850e.png
[image-20201227171157475]: /images/20221024/43c3d41ca6104cf7ac6e7f0fd8bd314e.png
[image-20201227171739495]: /images/20221024/44552a47fd434d6bbd5676a21ddd72f4.png
[image-20201227182248032]: /images/20221024/e11cd9ddd4b44dea85ed6176124a1711.png
[image-20201227180550246]: /images/20221024/d1b3f31312a0412898ca0ccf8b5a90c6.png
[image-20201227181324215]: /images/20221024/8795fb283778484487a5a48dcdc245a5.png
[image-20210120232821132]: /images/20221024/75571b70944a4e0da5c17c4f29222990.png
[image-20210120233544105]: /images/20221024/9cc7d7a786e94f45acb9d4a32962fad1.png
[image-20210120233844339]: /images/20221024/18af7e0f92b648bb9511fd3b2c29602e.png
[image-20210121111748695]: /images/20221024/7f0c9f35c09544948d4b22446a981e34.png
[image-20210121000608878]: /images/20221024/ef9b77f8ec0f4ad9b67d42e54ecc1218.png
[image-20210121001224590]: /images/20221024/3037b4c8694549d3a0501309ffc9476f.png
[image-20210121001449731]: /images/20221024/c400e5afb67549778a0cf8ab67bcb6f5.png
[image-20210121001548115]: /images/20221024/e8e3cb1ec3d048b8a7f1ad344884a8e9.png
[image-20210121111707355]: /images/20221024/e56ff5f28cea48e59fae0d4333e7578c.png
[image-20210121111228162]: /images/20221024/90d614b2c6234c2ba04339f3a8d6deae.png
[image-20210121112329193]: /images/20221024/e590bb5e546a425887521b0e76785580.png
[image-20210121112536036]: /images/20221024/433c4dbaeaa244f6b41732af0dcb4efa.png
[image-20210121113955304]: /images/20221024/a394af9744064eedbe55272e5438f323.png
[image-20210121114219194]: /images/20221024/e07221c0f6944cd6b8d4eb09a0a480f8.png
[image-20210121114934243]: /images/20221024/e73bff18dcc2408e9fc52cd368435a68.png
[image-20210121115330658]: /images/20221024/0bec45723b7944b0be224794e31aa2c7.png
[image-20210121115401635]: /images/20221024/0a2fedd3d91940d78c01029c83ea09c8.png
[image-20210121115655181]: /images/20221024/b091e3bc3fa1440b8f31a5cc1f0b618c.png
[image-20210121184512310]: /images/20221024/3ca9fe46a987434fab7f7c7ae18104b1.png
[image-20210121115807635]: /images/20221024/fdd4192e497a4cc5ba4c5ecad4632181.png
[image-20210121190805007]: /images/20221024/61e4726c5f6444dab4b640f7086807d3.png
[image-20210121191412693]: /images/20221024/bae33c8626b54d3a9b2fcb9169278574.png
[image-20210121204334235]: /images/20221024/9b7e4248fbd24a61aef043007b764254.png
[image-20210121204517530]: /images/20221024/13a8afd66cbd45349cabdd6e069a9f01.png
[image-20210121204530559]: /images/20221024/605c1a55f6b547b18534aa4b2aa0de7d.png
[image-20210121205727448]: /images/20221024/8fdd8350689e4360b194bfaa93f24d1b.png
[image-20210121211710519]: /images/20221024/7a5f9a783ee0409ab77143cb15ecf55f.png
[image-20210121212144368]: /images/20221024/192509076d524733bcc9d5a19650ea51.png
[image-20210121212702577]: /images/20221024/807739b4cc6140eab74355c41dd9b387.png
[image-20210121212502988]: /images/20221024/b7d007f7adfa4890be4fdcbfcbc76c73.png
[image-20210121222550561]: /images/20221024/7a2e2d6d2c7f48cf8026e3c68ac2ea3e.png
[image-20210121223354921]: /images/20221024/a874e56046bb4661b27a4337f594df4b.png
[image-20210121223722445]: /images/20221024/2a8cc34fabbd4cdb8c5c7dda03091e69.png
[image-20210121225757259]: /images/20221024/3b5c7cf554aa4c338f016a9f712e0fb4.png
[image-20210121224051493]: /images/20221024/4f9e9758331145c0abf4a2b2c1e1eccd.png
[image-20210121224352912]: /images/20221024/f97e5d2e11dc4edba05db80f48116f04.png
[image-20210121232036272]: /images/20221024/46a69d535ae34e35a94c70eafc05fcfe.png
[image-20210121232105858]: /images/20221024/0018f07d322d431da2a0822d75acaaa5.png
[image-20210121232208076]: /images/20221024/6c443929b5ab49beb6f66f3b86d6f032.png
[image-20210121232455853]: /images/20221024/e23286bce6c64f3e9a75df2f42aa0721.png
[image-20210121232611915]: /images/20221024/57886873c6724e829c8369cb1ee9308c.png
[image-20210121232831741]: /images/20221024/a8cd405d7cfe43e7a83c7ca56990251c.png
[image-20210121233243604]: /images/20221024/1760e18cf1b44b619a6978b33a349f9d.png
[image-20210121234116600]: /images/20221024/3a214589d7d94dd192426a9fd6e3a2b1.png
[image-20210121234331407]: /images/20221024/70a8a57b13764a75bed6623ad0df6810.png
[image-20210121234645513]: /images/20221024/a9a2b65340a34bf5b4f84c73ecfd63b7.png
[image-20210121234848286]: /images/20221024/2b7ac9ea03fb4c6191e0d36a10cf7911.png
[image-20210121235010086]: /images/20221024/6cd01f032ceb40c3b8a008a0007eb0ad.png
[image-20210121235357538]: /images/20221024/2e371cda94cd453cb4294e602efa7d36.png
[image-20210122101219469]: /images/20221024/233c44e4d1ca442aaf6a00d3a5604711.png