并发编程篇

一：乐观锁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不是写锁（解决写锁饥饿问题），就可以直接获取读锁资源。 写锁需要确保没有读线程在持有读锁，并且没有其他线程在持有写锁，写锁才能拿到锁资源。