Java 并发问题之 Java 8 如何优化 CAS 性能？

这篇文章给大家聊一下 java 并发包下的 CAS 相关的原子操作，以及 Java 8 如何改进和优化 CAS 操作的性能。

因为 Atomic 系列的原子类，无论在并发编程、JDK 源码、还是各种开源项目中，都经常用到。

1. 场景引入，问题凸现

假设多个线程需要对一个变量不停的累加 1，比如说下面这段代码：

public class Helloworld{
     private int data=0;
     //多个线程同时对data变量执行操作：data++
}

实际上，上面那段代码是不 ok 的，因为多个线程直接这样并发的对一个 data 变量进行修改，是线程不安全性的行为，会导致 data 值的变化不遵照预期的值来改变。

举个例子，比如说 20 个线程分别对 data 执行一次 data++ 操作，我们以为最后 data 的值会变成 20，其实不是。

最后可能 data 的值是 18，或者是 19，都有可能，因为多线程并发操作下，就是会有这种安全问题，导致数据结果不准确。

2. synchronized

所以，对于上面的代码，一般我们会改造一下，让他通过加锁的方式变成线程安全的：

public class Helloworld{
     private int data=0;
    
    public synchronized void increment(){
         data++;
    }
    //多个线程同时调用方法： inrement()
}

这个时候，代码就是线程安全的了，因为我们加了 synchronized，也就是让每个线程要进入 increment() 方法之前先得尝试加锁，同一时间只有一个线程能加锁，其他线程需要等待锁。

通过这样处理，就可以保证换个 data 每次都会累加 1，不会出现数据错乱的问题。

我们来看看下面的图，感受一下 synchronized 加锁下的效果和氛围，相当于 N 个线程一个一个的排队在更新那个数值。

但是，如此简单的 data++ 操作，都要加一个重磅的 synchronized 锁来解决多线程并发问题，就有点杀鸡用牛刀，大材小用了。

虽然随着 Java 版本更新，也对 synchronized 做了很多优化，但是处理这种简单的累加操作，仍然显得 “太重了”。人家 synchronized 是可以解决更加复杂的并发编程场景和问题的。

而且，在这个场景下，你要是用 synchronized，不就相当于让各个线程串行化了么？一个接一个的排队，加锁，处理数据，释放锁，下一个再进来。

3. Atomic 原子类及其底层原理

对于这种简单的 data++ 类的操作，其实我们完全可以换一种做法，java 并发包下面提供了一系列的 Atomic 原子类，比如说 AtomicInteger。

他可以保证多线程并发安全的情况下，高性能的并发更新一个数值。我们来看下面的代码：

public class Helloworld{
     private AtomicInteger data= new AtomicInteger (0) ;
     
     //多个线程并发执行：data.incrementAndGet()
}

大家看上面的代码，是不是很简单！多个线程可以并发的执行 AtomicInteger 的 incrementAndGet() 方法，意思就是给我把 data 的值累加 1，接着返回累加后最新的值。

这个代码里，就没有看到加锁和释放锁这一说了吧！

实际上，Atomic 原子类底层用的不是传统意义的锁机制，而是无锁化的 CAS 机制，通过 CAS 机制保证多线程修改一个数值的安全性

那什么是 CAS 呢？他的全称是：Compare and Set，也就是先比较再设置的意思。

我们来看上面的图，假如说有 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 是原子的，别人不会打断你！

通过这个机制，不需要加锁这么重量级的机制，也可以用轻量级的方式实现多个线程安全的并发的修改某个数值。

4. 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 分段数值加起来返回给你。

5. 总结 & 思考

不知道大家有没有发现这种高并发访问下的分段处理机制，在很多地方都有类似的思想体现！因为高并发中的分段处理机制实际上是一个很常见和常用的并发优化手段。

注：以上文献均摘抄自石衫架构笔记！！！