a++ 的问题
先写个 demo 的例子。把 a++ 放入多线程中运行一下。定义 10 个线程，每个线程里面都调用 5 次 a++，把 a 用 volatile 修饰，可以让 a 的值在修改之后，所有的线程立刻就可以知道。最后结果是不是 50，还是其他的数字?
从结果上看 a++ 的操作并没有达到预期值的 50，而是少了很多，其中还有一定是有问题的。那就是因为 a++ 的操作并不是原子性的。
原子性
并发编程，有三大原则：有序性、可见性、原子性
- 有序性：正常编译器执行代码，是按顺序执行的。有时候，在代码顺序对程序的结果没有影响时，编译器可能会为了性能从而改变代码的顺序。
- 可见性：一个线程修改了一个变量的值，另外一个线程立刻可以知道修改后的值。
- 原子性：一个操作或者多个操作在执行的时候，要么全部被执行，要么全部都不执行。
上面的 a++ 就没有原子性，它有三个步骤:
- 在内存中读取了 a 的值。
- 对 a 进行了 + 1 操作。
- 将新的 a 值刷回到内存。
这三个步骤可以被示例中的 10 个线程上下文切换打断：当 a = 10
- 线程 1 将 a 的值读取到内存， a = 10
- 线程 2 将 a 的值读取到内存， a = 10
- 线程 1 将 a + 1，a = 11
- 此时线程发生切换，线程 2 对 a 进行 + 1 操作, a = 11
- 线程 2 将 a 的值写回到内存， a = 11
- 线程 1 将 a 的值写回到内存, a = 11
从上面的步骤中可以看出 a 的值在两次相加后没有得到 12 的值，而是 11。这就是 a++ 引发的问题。
小 B 把上面的步骤对面试官讲了一遍，面试官又问了，有什么方式可以避免这个问题，小 B 不加思索的回答用 synchronized 加锁。面试官说 synchronized 太重了，还有其他的解决方式吗？小 B 晕了。其实可以使用 AtomicInteger 的 incrementAndGet() 方法。
AtomicInteger 源码分析
主要属性
首先看看 AtomicInteger 的主要属性。
从属性中可以看出 AtomicInteger 调用的是 Unsafe 类，Unsafe 类中大多数的方法是用 native 修饰的，可以直接进行一些系统级别的操作。
用 volatile 修饰 value 值，保证了一个线程的值对另外一个线程立即可见。
incrementAndGet()
incrementAndGet() 首先获取了当前值，然后调用 compareAndSwapInt() 方法更新数据。
compareAndSwapInt() 是 CAS 的缩写来源，比较并替换。被 native 修饰，调用了操作系统底层的方法，保证了硬件级别的原子性。
var2，var4，var5 是它的三个操作数，表示内存地址偏移量 valueOffset，预期原值 expect，新的值 update。把 this.compareAndSwapInt(var1, var2, var5, var5 + var4) 变成 this.compareAndSwapInt(obj, valueOffset, expect, update)，释义就是如果内存位置中的 valueOffset 值 与 expect 的值相同，就把内存中的 valueOffset 改成 update，否则不操作。
getAndAddInt() 方法中用了 do-while，就相当于如果 CAS 一直更新不成功，就不退出循环。直到更新成功为止。
ABA 问题
CAS 操作也并不是没有问题的。
- 循环操作时间长了，开销大。用了 do-while，如果更新一直不成功，就一直在循环。会给 CPU 带来很大的开销。
- 只能保证一个共享变量的原子性。循环 CAS 的方式只能保证一个变量进行原子操作，在对多个变量进行 CAS 的时候就没办法保证原子性了。
- ABA 问题。CAS 的操作一般是 1. 读取内存偏移量 valueOffset。2. 比较 valueOffset 和 expect 的值。3. 更新 valueOffset 的值。如果线程 A 读取 valueOffset 后，线程 B 修改了 valueOffset 的值，并且将 valueOffset 的值又改了回来。线程 A 会认为 valueOffset 的值并没有改变。这就是 ABA 问题。要解决这个问题，就是在每次修改 valueOffset 值的时候带上一个版本号。
总结
这篇文章介绍了 CAS，它是 java 中的乐观锁，每次认为操作并不会有其他线程去修改数据，如果有其他线程操作了数据，就重试，一直到成功为止。
我是指北君，操千曲而后晓声，观千剑而后识器。感谢各位人才的：点赞、收藏和评论，我们下期更精彩！
