Atomic 原子类与CAS
文章目录
- 1.场景引入，问题凸现
- 2.初步的解决方案：synchronized
- 3.更高效的方案：Atomic原子类及其底层原理
- 3.1.Atomic原子类是什么
- 3.2. JUC 包中的原子类是哪4类?
- 3.3.AtomicInteger 类常用方法
- 3.4.Atomic原子类如何解决我们的问题
- 3.5. 能不能给我简单介绍一下 AtomicInteger 类的原理
- 2.CAS
- 2.2.Java 8对CAS机制的优化——解决自旋
- 2.3.ABA问题
1.场景引入，问题凸现
假设多个线程需要对一个变量不停的累加1，比如说下面这段代码：
必然会导致线程不安全，最后的data十有八九会比我们预期的值小，为什么？
因为data++看似是1步，其实是三步：取值、修改值、赋值，这中间可能会被插队导致比预期小。
我们怎么来解决这种问题呢？
2.初步的解决方案：synchronized
所以，对于上面的代码，一般我们会改造一下，让他通过加锁的方式变成线程安全的：
这个时候，代码就是线程安全的了，因为我们加了synchronized，也就是让每个线程要进入increment()方法之前先得尝试加锁，同一时间只有一个线程能加锁，其他线程需要等待锁。
这种方法肯定能解决问题，但是我们都知道synchronized是重量锁，这种方式太慢了，而且杀鸡焉用牛刀？
3.更高效的方案：Atomic原子类及其底层原理
3.1.Atomic原子类是什么
Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。
所以，所谓原子类说简单点就是具有原子/原子操作特征的类。在上面那个data++例子中，原子类可以保证这三步要么都执行，要么都不执行。所以它可以作为计数器。
并发包java.util.concurrent的原子类都存放在java.util.concurrent.atomic下,如下图所示。
3.2. JUC 包中的原子类是哪4类?
基本类型
使用原子的方式更新基本类型
- AtomicInteger：整形原子类
- AtomicLong：长整型原子类
- AtomicBoolean：布尔型原子类
数组类型
使用原子的方式更新数组里的某个元素
- AtomicIntegerArray：整形数组原子类
- AtomicLongArray：长整形数组原子类
- AtomicReferenceArray：引用类型数组原子类
引用类型
- AtomicReference：引用类型原子类
- AtomicStampedReference：原子更新引用类型里的字段原子类
- AtomicMarkableReference ：原子更新带有标记位的引用类型
对象的属性修改类型
- AtomicIntegerFieldUpdater：原子更新整形字段的更新器
- AtomicLongFieldUpdater：原子更新长整形字段的更新器
- AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。
3.3.AtomicInteger 类常用方法
public final int get() //获取当前的值
public final int getAndSet(int newValue)//获取当前的值，并设置新的值
public final int getAndIncrement()//获取当前的值，并自增
public final int getAndDecrement() //获取当前的值，并自减
public final int getAndAdd(int delta) //获取当前的值，并加上预期的值
boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将该值设置为输入值（update）
public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet
3.4.Atomic原子类如何解决我们的问题
大家看上面的代码，是不是很简单！多个线程可以并发的执行AtomicInteger的incrementAndGet()方法，意思就是给我把data的值累加1，接着返回累加后最新的值。
这个代码里，就没有看到加锁和释放锁这一说了吧！
实际上，Atomic原子类底层用的不是传统意义的锁机制，而是无锁化的CAS机制，通过CAS机制保证多线程修改一个数值的安全性
那什么是CAS呢？他的全称是：Compare and Set，也就是先比较再设置的意思。
3.5. 能不能给我简单介绍一下 AtomicInteger 类的原理
AtomicInteger 线程安全原理简单分析
AtomicInteger 类的部分源码：
// setup to use Unsafe.compareAndSwapInt for updates（更新操作时提供“比较并替换”的作用）
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;
AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。
CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个volatile变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。
2.CAS
我们来看上面的图，假如说有3个线程并发的要修改一个AtomicInteger的值，他们底层的机制如下：
首先，每个线程都会先获取当前的值，接着走一个原子的CAS操作，原子的意思就是这个CAS操作一定是自己完整执行完的，不会被别人打断。
然后CAS操作里，会比较一下说，唉！大兄弟！现在你的值是不是刚才我获取到的那个值啊？放弃修改。
如果是的话，bingo！说明没人改过这个值，那你给我设置成累加1之后的一个值好了！
同理，如果有人在执行CAS的时候，发现自己之前获取的值跟当前的值不一样，会导致CAS失败，失败之后，进入一个无限循环，再次获取值，接着执行CAS操作！
好！现在我们对照着上面的图，来看一下这整个过程：
-
首先第一步，我们假设线程一咔嚓一下过来了，然后对AtomicInteger执行incrementAndGet()操作，他底层就会先获取AtomicInteger当前的值，这个值就是0。
-
此时没有别的线程跟他抢！他也不管那么多，直接执行原子的CAS操作，问问人家说：兄弟，你现在值还是0吗？
-
如果是，说明没人修改过啊！太好了，给我累加1，设置为1。于是AtomicInteger的值变为1！
-
接着线程2和线程3同时跑了过来，因为底层不是基于锁机制，都是无锁化的CAS机制，所以他们俩可能会并发的同时执行incrementAndGet()操作。
-
然后俩人都获取到了当前AtomicInteger的值，就是1
-
接着线程2抢先一步发起了原子的CAS操作！注意，CAS是原子的，此时就他一个线程在执行！
-
然后线程2问：兄弟，你现在值还是1吗？如果是，太好了，说明没人改过，我来改成2
-
好了，此时AtomicInteger的值变为了2。关键点来了：现在线程3接着发起了CAS操作，但是他手上还是拿着之前获取到的那个1啊！
-
线程3此时会问问说：兄弟，你现在值还是1吗？
-
噩耗传来！！！这个时候的值是2啊！线程3哭泣了，他说，居然有人在这个期间改过值。算了，那我还是重新再获取一次值吧，于是获取到了最新的值，值为2。
-
然后再次发起CAS操作，问问，现在值还是2吗？是的！太好了，没人改，我抓紧改，此时AtomicInteger值变为3！
上述整个过程，就是所谓Atomic原子类的原理，没有基于加锁机制串行化，而是基于CAS机制：先获取一个值，然后发起CAS，比较这个值被人改过没？如果没有，就更改值！这个CAS是原子的，别人不会打断你！
通过这个机制，不需要加锁这么重量级的机制，也可以用轻量级的方式实现多个线程安全的并发的修改某个数值。
在JUC包下的原子类也是通过这个实现的，我们来举个栗子
以AtomicInteger举例，他的自增函数incrementAndGet（）就是这样实现的，其中就有大量循环判断的过程，直到符合条件才成功。
大概意思就是循环判断给定偏移量是否等于内存中的偏移量，直到成功才退出，看到do while的循环没。
2.2.Java 8对CAS机制的优化——解决自旋
但是这个CAS有没有问题呢？肯定是有的。比如说大量的线程同时并发修改一个AtomicInteger，可能有很多线程会不停的自旋，进入一个无限重复的循环中。
这些线程不停地获取值，然后发起CAS操作，但是发现这个值被别人改过了，于是再次进入下一个循环，获取值，发起CAS操作又失败了，再次进入下一个循环。
在大量线程高并发更新AtomicInteger的时候，这种问题可能会比较明显，导致大量线程空循环，自旋转，性能和效率都不是特别好。
于是，当当当当，Java 8推出了一个新的类，LongAdder，他就是尝试使用分段CAS以及自动分段迁移的方式来大幅度提升多线程高并发执行CAS操作的性能！
在LongAdder的底层实现中，首先有一个base值，刚开始多线程来不停的累加数值，都是对base进行累加的，比如刚开始累加成了base = 5。
接着如果发现并发更新的线程数量过多，就会开始施行分段CAS的机制，也就是内部会搞一个Cell数组，每个数组是一个数值分段。
这时，让大量的线程分别去对不同Cell内部的value值进行CAS累加操作，这样就把CAS计算压力分散到了不同的Cell分段数值中了！
这样就可以大幅度的降低多线程并发更新同一个数值时出现的无限循环的问题，大幅度提升了多线程并发更新数值的性能和效率！
而且他内部实现了自动分段迁移的机制，也就是如果某个Cell的value执行CAS失败了，那么就会自动去找另外一个Cell分段内的value值进行CAS操作。
这样也解决了线程空旋转、自旋不停等待执行CAS操作的问题，让一个线程过来执行CAS时可以尽快的完成这个操作。
最后，如果你要从LongAdder中获取当前累加的总值，就会把base值和所有Cell分段数值加起来返回给你。
2.3.ABA问题
看到问题所在没，我说一下顺序：
-
线程1读取了数据A
-
线程2读取了数据A
-
线程2通过CAS比较，发现值是A没错，可以把数据A改成数据B
-
线程3读取了数据B
-
线程3通过CAS比较，发现数据是B没错，可以把数据B改成了数据A
-
线程1通过CAS比较，发现数据还是A没变，就写成了自己要改的值
在这个过程中任何线程都没做错什么，但是值被改变了，线程1却没有办法发现，其实这样的情况出现对结果本身是没有什么影响的，但是我们还是要防范。
如何解决ABA问题？
- JDK 1.5 以后的
AtomicStampedReference类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。 - 加时间戳。修改时看看时间戳一不一致，如果一致就更改然后更新时间戳
- 加版本号。修改时看看版本号一不一致，如果一致就更改然后版本号+1
比如：
之前不能防止ABA的正常修改：
update table set value = newValue where value = #{oldValue}
//oldValue就是我们执行前查询出来的值
带版本号能防止ABA的修改：
update table set value = newValue ，vision = vision + 1 where value = #{oldValue} and vision = #{vision}
// 判断原来的值和版本号是否匹配，中间有别的线程修改，值可能相等，但是版本号100%不一样
参考文章：
大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？【石杉的架构笔记】
https://github.com/Snailclimb/JavaGuide/blob/master/docs/java/Multithread/JavaConcurrencyAdvancedCommonInterviewQuestions.md