1. 聊聊 lock 锁中的公平和非公平锁
    • 公平锁指的就是：在竞争环境下，先到临界区的线程比后到的线程一定更快地获取得到锁
    • 非公平指的就是：先到临界区的线程未必比后到的线程更快地获取得到锁
    1. 让你实现的话，你怎么实现公平和非公平锁
    • 公平锁
      • 可以把竞争的线程放在一个先进先出的队列上
      • 只要持有锁的线程执行完了，唤醒队列的下一个线程去获取锁就好了
    • 非公平锁
      • 线程先尝试能不能获取得到锁，如果获取得到锁了就执行同步代码了
      • 如果获取不到锁，那就再把这个线程放到队列呗
    • 公平和非公平的实现区别
      • 线程执行同步代码块时，是否会去尝试获取锁。
      • 如果会尝试获取锁，那就是非公平的。如果不会尝试获取锁，直接进队列，再等待唤醒，那就是公平的
      • AQS和ReentrantLock - 图1
    1. 为什么要进队列呢？线程一直尝试获取锁不就行了么
    • 一直尝试获取锁，专业点就叫做自旋，需要耗费资源的。
    • 多个线程一直在自旋，而且大多数都是竞争失败的，哪有人会这样实现的
    1. synchronized锁是公平的还是非公平的？
    • 非公平的。AQS和ReentrantLock - 图2
    • 偏向锁很好理解
      • 如果当前线程 ID 与 markword 存储的不相等，则 CAS 尝试更换线程 ID，CAS 成功就获取得到锁了 —> 这就是线程尝试获取锁，而不是进队列等唤醒
      • CAS失败则升级为轻量级锁
    • 轻量级锁
      • 也是通过CAS来抢占锁资源（只不过多了拷贝Mark Word到Lock Record的过程）
      • 抢占成功到锁就归属给该线程了，但自旋失败一定次数后升级重量级锁
    • 重量级锁
      • 通过 monitor 对象中的队列存储线程，但线程进入队列前，还是会先尝试获取得到锁，如果能获取不到才进入线程等待队列中
    • 综上所述
      • synchronized 无论处理哪种锁，都是先尝试获取，获取不到才升级或放到队列上的，所以是非公平的
    1. AQS 你了解吗
    • AQS 全称叫做 AbstractQueuedSynchronizer
    • 是可以给我们实现锁的一个「框架」，内部实现的关键就是维护了一个先进先出的队列以及state状态变量
    • 先进先出队列存储的载体叫做 Node 节点，该节点标识着当前的状态值、是独占还是共享模式以及它的前驱和后继节点等等信息
    • 简单理解就是：AQS定义了模板，具体实现由各个子类完成。
    • 总体的流程可以总结为：会把需要等待的线程以Node的形式放到这个先进先出的队列上，state变量则表示为当前锁的状态。
    • 像 ReentrantLock、ReentrantReadWriteLock、CountDownLatch、Semaphore 这些常用的实现类都是基于AQS实现的
    • AQS支持两种模式：独占（锁只会被一个线程独占）和共享（多个线程可同时执行）
    • AQS和ReentrantLock - 图3
    1. 以 ReentrantLock 来讲讲加锁和解锁的过程
    • 以非公平锁为例
    • 外界调用 lock 方法的时候，也即加锁过程：
      • 简单过程：
        • 当线程 CAS 获取锁失败，将当前线程入队列，把前驱节点状态设置为 SIGNAL 状态，并将自己挂起
        • AQS和ReentrantLock - 图4
      • 复杂过程：
        • 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将当前线程挂起
    • 解锁的过程
      • 简单过程：
        • 把state置0，唤醒头结点下一个合法的节点，被唤醒的节点线程自然就会去获取锁
      • 详细过程：
        • 1)：外界调用 unlock 方法时，实际上会调用 AQS 的 release 方法，而 release 方法会调用子类 tryRelease 方法（又回到了ReentrantLock中）
        • 2)：tryRelease 会把 state 一直减（锁重入可使state>1），直至到0，当前线程说明已经把锁释放了
        • 3)：随后从队尾往前找节点状态需要 < 0，并离头节点最近的节点进行唤醒
        • 唤醒之后，被唤醒的线程则尝试使用CAS获取锁，假设获取锁得到则把头节点给干掉，把自己设置为头节点
    1. 解锁过程中，线程CAS获取锁失败，为什么要设置前驱节点为SIGNAL状态，有啥用？
    • 表示后继节点需要被唤醒
    • 归终结底就是为了判断节点的状态，去做些处理。
    • Node 中节点的状态有4种，分别是：CANCELLED(1)、SIGNAL(-1)、CONDITION(-2)、PROPAGATE(-3)和0
    • 在ReentrantLock解锁的时候，会判断节点的状态是否小于0，小于等于0才说明需要被唤醒
    • 另外一提的是：
      • 公平锁的实现与非公平锁是很像的，只不过在获取锁时不会直接尝试使用CAS来获取锁。
      • 只有当队列没节点并且state为0时才会去获取锁，不然都会把当前线程放到队列中

    AQS和ReentrantLock - 图5