三歪：淦，已经熬到了第8面了

    三歪：上次已经透露要问lock锁了，嘿嘿，这几天我又学会了不少

    三歪：问lock锁肯定会讲AQS的

    三歪：有一说一，这面试官问的题目还是可以的

    三歪：当然了，我答得也还行

    三歪：面试官你好，请问面试可以开始了吗？

    面试官：嗯，开始了。

    面试官：今天我们来聊聊lock锁吧？

    三歪：嗯嗯嗯，没问题

    面试官：先问点简单的吧，刚睡醒，还是有点困的。

    三歪：刚睡醒来面我干嘛？你就这态度？

    面试官：哈？你刚说了什么？

    三歪：没事，我没说话…

    面试官：你知道什么叫做公平和非公平锁吗

    三歪：公平锁指的就是：在竞争环境下，先到临界区的线程比后到的线程一定更快地获取得到锁

    三歪：那非公平就很好理解了：先到临界区的线程未必比后到的线程更快地获取得到锁

    面试官：如果让你实现的话，你怎么实现公平和非公平锁？

    三歪：公平锁可以把竞争的线程放在一个先进先出的队列上

    三歪：只要持有锁的线程执行完了，唤醒队列的下一个线程去获取锁就好了

    三歪：非公平锁的概念上面已经提到了：后到的线程可能比前到临界区的线程获取得到锁

    三歪：那实现也很简单，线程先尝试能不能获取得到锁，如果获取得到锁了就执行同步代码了

    三歪：如果获取不到锁，那就再把这个线程放到队列呗

    三歪：所以公平和非公平的区别就是：线程执行同步代码块时，是否会去尝试获取锁。

    三歪：如果会尝试获取锁，那就是非公平的。如果不会尝试获取锁，直接进队列，再等待唤醒，那就是公平的。

    面试官：为什么要进队列呢？线程一直尝试获取锁不就行了么？

    三歪：一直尝试获取锁，专业点就叫做自旋，需要耗费资源的。

    三歪：多个线程一直在自旋，而且大多数都是竞争失败的，哪有人会这样实现的

    三歪：不会吧，不会吧，你不会就是这样实现的吧

    面试官：我就问问…

    面试官：那上次面试所问的synchronized锁是公平的还是非公平的？

    三歪：非公平的。

    三歪：偏向锁很好理解，如果当前线程ID与markword存储的不相等，则CAS尝试更换线程ID，CAS成功就获取得到锁了

    三歪：CAS失败则升级为轻量级锁

    三歪：轻量级锁实际上也是通过CAS来抢占锁资源（只不过多了拷贝Mark Word到Lock Record的过程）

    三歪：抢占成功到锁就归属给该线程了，但自旋失败一定次数后升级重量级锁

    三歪：重量级锁通过monitor对象中的队列存储线程，但线程进入队列前，还是会先尝试获取得到锁，如果能获取不到才进入线程等待队列中

    三歪：综上所述，synchronized无论处理哪种锁，都是先尝试获取，获取不到才升级|| 放到队列上的，所以是非公平的

    面试官：嗯，讲得挺仔细的。AQS你了解吗？

    三歪：嗯嗯，AQS全称叫做AbstractQueuedSynchronizer

    三歪：是可以给我们实现锁的一个「框架」，内部实现的关键就是维护了一个先进先出的队列以及state状态变量

    三歪：先进先出队列存储的载体叫做Node节点，该节点标识着当前的状态值、是独占还是共享模式以及它的前驱和后继节点等等信息

    三歪：简单理解就是：AQS定义了模板，具体实现由各个子类完成。

    三歪：总体的流程可以总结为：会把需要等待的线程以Node的形式放到这个先进先出的队列上，state变量则表示为当前锁的状态。

    三歪：像ReentrantLock、ReentrantReadWriteLock、CountDownLatch、Semaphore这些常用的实现类都是基于AQS实现的

    三歪：AQS支持两种模式：独占（锁只会被一个线程独占）和共享（多个线程可同时执行）

    面试官：你以ReentrantLock来讲讲加锁和解锁的过程呗

    三歪：以非公平锁为了，我们在外界调用lock方法的时候，源码是这样实现的

    三歪：1):CAS尝试获取锁，获取成功则可以执行同步代码

    三歪：2):CAS获取失败，则调用acquire方法，acquire方法实际上就是AQS的模板方法

    三歪：3):acquire首先会调用子类的tryAcquire方法（又回到了ReentrantLock中）

    三歪：4):tryAcquire方法实际上会判断当前的state是否等于0，等于0说明没有线程持有锁，则又尝试CAS直接获取锁

    三歪：5):如果CAS获取成功，则可以执行同步代码

    三歪：6):如果CAS获取失败，那判断当前线程是否就持有锁，如果是持有的锁，那更新state的值，获取得到锁（这里其实就是处理可重入的逻辑）

    三歪：7):CAS失败&&非重入的情况，则回到tryAcquire方法执行「入队列」的操作

    三歪：8):将节点入队列之后，会判断「前驱节点」是不是头节点，如果是头结点又会用CAS尝试获取锁

    三歪：9):如果是「前驱节点」是头节点并获取得到锁，则把当前节点设置为头结点，并且将前驱节点置空（实际上就是原有的头节点已经释放锁了）

    三歪：10):没获取得到锁，则判断前驱节点的状态是否为SIGNAL，如果不是，则找到合法的前驱节点，并使用CAS将状态设置为SIGNAL

    三歪：11):最后调用park将当前线程挂起

    面试官：你说了一大堆，麻烦使用压缩算法压缩下加锁的过程。

    三歪：压缩后：当线程CAS获取锁失败，将当前线程入队列，把前驱节点状态设置为SIGNAL状态，并将自己挂起。

    面试官：为什么要设置前驱节点为SIGNAL状态，有啥用？

    三歪：其实就是表示后继节点需要被唤醒

    三歪：我先把解锁的过程说下吧

    三歪：1):外界调用unlock方法时，实际上会调用AQS的release方法，而release方法会调用子类tryRelease方法（又回到了ReentrantLock中）

    三歪：2):tryRelease会把state一直减（锁重入可使state>1），直至到0，当前线程说明已经把锁释放了

    三歪：3):随后从队尾往前找节点状态需要 < 0，并离头节点最近的节点进行唤醒

    三歪：唤醒之后，被唤醒的线程则尝试使用CAS获取锁，假设获取锁得到则把头节点给干掉，把自己设置为头节点

    三歪：解锁的逻辑非常简单哈，把state置0，唤醒头结点下一个合法的节点，被唤醒的节点线程自然就会去获取锁

    三歪：回到上一个问题，为什么要设置前驱节点为SIGNAL状态

    三歪：其实归终结底就是为了判断节点的状态，去做些处理。

    三歪：Node 中节点的状态有4种，分别是：CANCELLED(1)、SIGNAL(-1)、CONDITION(-2)、PROPAGATE(-3)和0

    三歪：在ReentrantLock解锁的时候，会判断节点的状态是否小于0，小于等于0才说明需要被唤醒

    三歪：另外一提的是：公平锁的实现与非公平锁是很像的，只不过在获取锁时不会直接尝试使用CAS来获取锁。

    三歪：只有当队列没节点并且state为0时才会去获取锁，不然都会把当前线程放到队列中

    面试官：嗯，了解了。

    面试官：我发现你这是真能吹啊，我就问了点，你就巴拉巴拉在讲

    面试官：导致我面一次，就问了这么点知识

    面试官：装逼？下次问你线程池，答不出来就把你挂了

    面试官：最后画个流程图吧，你画好了，他们会给你点赞和转发的

    三歪：真的假的？