这是我参考的一篇文章《基于CAS的乐观锁实现》，讲述的是一种需要CPU支持的执行技术CAS（Compare and Swap）。
首先理解什么是原子性操作，意思是不能再拆分的操作，例如改写一个值，读取一个值都属于原子性操作。
那么CAS是两个操作，先比较旧值，比较通过后再进行改写，这种连合操作合并成一个指令交给CPU，由CPU操作来确保这是一个原子性操作。
多线程同时改写同一个值时，每个线程携带自己的旧值和新值交给CPU改写，CPU的运行是按逐条指令运行，如果发现旧值不符合，线程就会收到改写失败回应。
public final int incrementAndGet() { for (;;) { int current = get(); int next = current + 1; if (compareAndSet(current, next)) return next; } }
因此AtomicInteger#incrementAndGet()方法里，会循环尝试使用compareAndSet(...)方法，直到成功为止。
相关的原子类所在包：java.util.concurrent.atomic
- Atomic + Boolean/Integer/Long/Reference
操作一个对应的类型对象 -
Atomic + Integer/Long/Reference + Array
操作一个对应类型的数组 - Atomic + Integer/Long/Reference + FieldUpdater
操作一个对应类型的Field对象，类似反射方式改写对象字段
这里《AtomicStampedReference解决ABA问题》，讲述了原子类会出现ABA时带来的隐患，文中举了一个例子，一个单向的链表实现了堆栈操作，使用一个原子变量作为链头指针，现在链头是A，A的next是B。有两个线程分别是T1和T2，他们并发的操作如下：
- T1：AB => B
- T2：AB => B => 空 => D => CD => ACD
由于线程T1只认链头是不是A，如果是A，就会将链头指向B，因此可能会出现直接把ACD变成B，这就是ABA并发的隐患。
- AtomicMarkableReference
操作一个对象类型和boolean类型的二元组 - AtomicStampedReference
操作一个对象类型和int类型的二元组
虽然例子中链头指针是一个原子变量，会出现ABA的情况，但如果再增加一个原子变量，这个原子变量确保不会出现ABA的情况，两个原子变量作为二元组进行原子性操作，即使用AtomicStampedReference就可以有效解决这个ABA的隐患了。
以下是Java8增加的原子类：
- Striped64
- Long/Double + Adder
- Long/Double + Accumulator
这里有两篇文章，内容是分析它们的源码：《从LongAdder 看更高效的无锁实现》，《LongAdder和LongAccumulator》
源码有些复杂，我也没看完，Striped64是这项新原子类的基类，它提供的原理是，把一个原子数拆分成多个原子数，最后把这多个原子数合成一个数。换句话说，原本在一个数上做递增或者递减操作的，现在变成在多个数里，选择其中一个做做递增或递减操作，那么加起来的结果与原本方式的结果是等价的。虽然是等价，但它结算结果的过程，是需要把多个数加起来，这个过程已经不是线程安全了，所以它的应用场合相比原本方式会宽一点，原本方式所取出来的值可以作为唯一ID，但现在方式只能用于统计。试想，如果有1000个线程同时在统计同一个数据，那么原本方式的原子类，就会失败率上升，效率也会随之下降。但如果把1000个线程，分成10份，每100个线程统计同一个数据，那么产生10个数据，最后统计的结果就是这10个数据叠加一起的结果，失败率当然因份数的增加而减少，效率也自然有保障。
应用场合：高并发，统计数据。