一：乐观锁CAS和自旋锁的关系
自旋锁是基于CAS实现的。
CAS没有自旋或者重试的效果，但是自旋锁是基于类似do-while的形式，不断尝试，直到成功为止。
CAS本质就是Unsafe类中的一个方法，他只会尝试一次，成功返回true，失败返回false。
CAS并不是在Java端实现的一个功能，而是在C++里面做的。
最终CAS会被翻译成一个指令。Atomic::cmpxchg，而这个指令是CPU原语，CPU认识这个指令。
二：CAS的效果是什么，在Java中如何使用CAS
CAS就是比较和交换，就是将内存中的某一个值，从oldValue，替换为newValue。替换的过程是先用oldValue比较内存值，如果一致，就替换，然后返回true。如果比较不一致，返回false。
比较和交换这两个操作是一条指令实现的。
Java中想用CAS操作的话，无法直接通过new或者是他提供的静态方法，直接使用。会抛出java.lang.SecurityException: Unsafe异常。
想用的话，unsafe类的对象需要通过反射的方式拿到。
public class MyTestCAS { private int value = 1; public static void main(String[] args) throws Exception { MyTestCAS test = new MyTestCAS(); Unsafe unsafe = null; Field field = Unsafe.class.getDeclaredField("theUnsafe"); field.setAccessible(true); unsafe = (Unsafe) field.get(null); // 获取内存偏移量 long offset = unsafe.objectFieldOffset(MyTest.class.getDeclaredField("value")); // 执行CAS，这里的四个参数分别代表什么，你也要清楚~ System.out.println(unsafe.compareAndSwapInt(test, offset, 0, 11)); System.out.println(test.value); } }
三：CAS常见问题，以及如何解决
ABA问题：不一定是问题，大多数情况下，只存在++，--这种操作时，无所谓你这个值是否被改过。对最终结果和业务没影响的，不需要考虑。
如果要求整个过程的变化不存在并发问题，不能出现ABA的情况，就必须追加类似版本号的效果，Java中也提供了AtmoicStampedReference
自旋次数过多：
- 自旋一定次数，就挂起线程，别CAS了，浪费CPU资源。
- 采用分段锁的形式，不要专注于一个属性，如果业务允许，可以分开计算，最终汇总。
CAS本质无法锁住一段代码，只能保证修改一个属性的原子性：But，ReentrantLock就是基于CAS的原子性类实现锁住一段代码的。
四：synchronized的锁升级过程
无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁？是这么一步一步走过来的么？
其实状态不是这样一点一点来的。
无锁无法到偏向锁
偏向锁是可以到无锁状态的，偏向锁没有地儿存储hashcode之类的值，为了存储，要么升级到轻量级锁，存储到LockRecord里，要么降级为无锁，存在MarkWord里。
五：AQS是什么
先说清楚和JUC的关系以及说和JUC下其他类的关系，然后说内部的核心结构。你可以往你会的地方拐。
AQS本质就是JUC包下的一个抽象类，JUC包下的一些并发工具，并发集合，线程池，锁都是基于AQS作为基础类去实现的。
AQS里面有一个核心属性和两个核心的结构：
- volatile修改是，并且基于CAS修改的state属性。
- 由Node组成的一个双向链表，或者说叫同步队列。
- 由Node组成的一个单向链表，这个是用于实现类似synchronized的wait和notify的结构。
六：ReentrantLock获取锁的方式
- lock
- tryLock()
- tryLock(time,unit)
- lockInterruptibly
lock方法：死等，如果那不到锁，就一直等，你interrupt中断了也一直等。
tryLock()方法：浅尝一下，试一下，就一下，拿到快乐的返回true，拿不到，返回false。
tryLock(time,unit)方法：尝试time.unit这么尝试时间，如果拿到了，返回true，时间到了，没拿到，返回false。如果在拿的过程中，线程中断了，就抛出异常。
lockInterruptibly方法：死等，如果那不到锁，就一直等，如果被interrupt中断了，抛出异常
七：AQS中node的几种状态
Node有5种状态，1，0，-1，-2，-3
- 1：代表当前Node已经取消了，不排队了。
- 0：代表代表默认状态，啥事没有~
- -1：代表当前节点的next Node挂起了，需要被唤醒
- -2：当前Node被await挂起了，扔到了Condition的单向链表里。
- -3：传播用的，共享资源里会用到，读线程拿到锁资源后，如果同步队列里排的是共享资源Node，那就继续唤醒。
八：AQS中取消结点的过程
想拿资源的线程在排队，但是不想排了，需要取消排队的Node。
1、将排队的Node里的线程设置为null
2、跳过取消的前继节点，找到有效节点连接上
3、将Node的状态设置为1，代表取消
4、后续节点操作，分为几种情况
- 取消的节点是tail：直接更换尾节点为有效的前继节点
- 取消的节点不是head.next：确保后继节点可以被唤醒，将前继节点设置为-1。
- 取消的节点是head.next：直接唤醒后继节点。
5、将取消的节点的next指向自己
九：AQS中被唤醒时，head.next有问题时，怎么找
是从队列从后往前找，因为如果next后取消的节点，取消节点会将next指向自己，直接找不到了。
另外，节点加入的顺序，是先连接prev，再连接tail，最后将前继节点的next指向自己。
在AQS里，prev指针始终是正确的，next说不定。
十：为什么会有ReentrantReadWriteLock
首先，读写锁能解决的，互斥锁肯定能解决，但是，互斥锁的效率可能比较低。
比如说有一个业务，平均下来，10次读操作，1次写操作。
如果用互斥锁，可以保证线程安全，但是10次读操作也需要一个一个来。
但是，读读操作没有线程安全问题。
但是只要涉及到了写操作，比如读写操作，需要保证线程安全。只要有写线程，就必须满足互斥性。
所以JUC下就提供了一个ReentrantReadWriteLock，读写锁。这个锁的特点，就是读读可以一起操作，但是只要涉及到了写操作，就必须保证互斥。
十一：ReentrantReadWriteLock 是如何基于AQS实现的
lock锁，无论是读锁还是写锁，都是基于state属性判断的。
state是int，占32个bit为，将高16为，作为读锁的标识，低16位，作为写锁的标识。
如果线程要拿读锁，只需要确认没有写线程在持有写锁资源，并且队列中的head.next不是写锁（解决写锁饥饿问题），就可以直接获取读锁资源。
写锁需要确保没有读线程在持有读锁，并且没有其他线程在持有写锁，写锁才能拿到锁资源。
