本文有几个小点或许是您看到的其他技术贴上未被提及的，相信看完会有所收获
大家都知道，多线程下操作共享变量，会出现所谓的“线程安全问题”从而不能得到我们预期的结果，为了解决这种问题，在早期的JDK版本中，提供的
synchronized关键字来解决这种线程安全问题，而在JDK1.5以后的java.util.concurrent包中，里面大量使用了一种叫CAS的技术，提供了一种不用synchronized的前提下解决线程安全问题的方案。本文将从AtomicInteger包入手，讲解CAS的原理和使用、以及CAS可能出现的问题
先来一个小demo
不想上来就贴上来千篇一律的各种概念，懂得人我不说也懂，不懂得看完概念依然不懂，用码说话，先看个小demo，开五个线程，每个线程累计1000次操作共享变量，共享变量分别使用int和基于CAS的AtomicInteger
public class AtomicTest {
int count = 0;
AtomicInteger atomicInteger = new AtomicInteger(0);
// 加1操作
public void add() {
count++;
atomicInteger.addAndGet(1);
}
public static void main(String[] args) throws InterruptedException {
AtomicTest atomicTest = new AtomicTest();
List<Thread> threads = new ArrayList<>();
// 开5个线程
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(() -> {
// 每个线程执行1000次add方法
for (int num = 0; num < 1000; num++) {
atomicTest.add();
}
});
threads.add(thread);
thread.start();
}
// 保证上面开启的五个线程执行在main线程之前
for (Thread thread : threads) {
thread.join();
}
System.out.println("count-->" + atomicTest.count);
System.out.println("atomic-->" + atomicTest.atomicInteger);
}
}
结果可能每次都不一样，但是使用AtomicInteger的值每次必是5000
count-->3670
atomic-->5000
Process finished with exit code 0
点进源码看一下
（基于JDK1.8，不用版本可能稍有不同）
点进atomicInteger.addAndGet(1);
/**
* Atomically adds the given value to the current value.
*
* @param delta the value to add
* @return the updated value
*/
public final int addAndGet(int delta) {
return unsafe.getAndAddInt(this, valueOffset, delta) + delta;
}
只有一行代码，然后调用了unsafe的getAndAddInt，传参分别是当前对象引用，valueOffset和我们要增加的值delta，valueOffset我们一会详细说一下，现在先点到unsafe.getAndAddInt(this, valueOffset, delta)中看一下
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
我们看到，进入了一个叫Unsafe的类中，首先先调取this.getIntVolatile(var1, var2);，这是一个native方法，通过传入的var1（也就是上面AtomicInteger的this）和var2，从内存中获取到最新的值，然后执行compareAndSwapInt(var1, var2, var5, var5 + var4)方法，就是我们的主角CAS（Compare and Swap），依然是native方法，实现原理是拿当前获取到的值（var5）通内存的值比较，如果值相同，则将内存的值更新为新的值（var5+var4，var4也就是我们上面传入的delta），如果与内存中的值不同，则继续执行do中的逻辑，获取最新的var5并继续执行compareAndSwap操作，直至成功。
其实CAS直至JDK1.5才被广泛使用的原因是，CAS是需要硬件支持的，随着处理器的发展，逐渐提供了将一系列操作原子操作的指令，其中CAS底层使用的就是CMPXCHG指令。
回到上面这段代码，看到最后return的值为var5，并不是执行操作后最新的值，当返回var5后，addAndGet(int delta)中，再加上delta，其实大家想一想，这样操作，虽然能保证AtomicInteger内部每次操作都是原子性的，却不能保证每次调用addAndGet方法返回的数据是顺序的，换句话说，它能保证结果的最终一致性，但是并不能保证每条线程中间状态的一致性，这也是为什么atomic包的类适合计数，但并不适合做例如生成订单号等要求强顺序的业务操作。
重点说下valueOffset
回过头来，看下刚刚还没解释的valueOffset，是个啥。valueOffset，存于AtomicInteger的成员变量中，在静态代码块中初始化
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
然后整个AtomicInteger中并没有修改它的地方。说明这个值在整个JVM中是唯一的，一个唯一的值，还被频繁传到各种native方法中，有什么意义的？当我们创建了一个对象之后，在内存中开辟了一片空间，但是这个对象的这片空间中，也是存放了各种数据的，这些对象怎么存放样式，被称作“布局”，而这个valueOffset，就是获取的一个字段在这个布局中的一个相对位置，叫着“偏移量”，根据上面代码我们看到获取的是value，这样，通过当前对象和value的偏移量，可以在内存中快速的定位到value的值。
说到 CAS不得不说的ABA问题
CAS看起来不会有任何问题，完美解决了多线程下数据安全问题，但是可能有这样一个场景
线程1:
获取内存中的值，为A
然后被挂起
线程2：
获取内存中的值，为A
修改A为B
修改B为A
执行完毕
线程1:
获取到的值A与内存中比对一致，可以操作
上述场景就出现了ABA问题，关于ABA问题会造成的问题，感兴趣的小伙伴可以查一查深入了解，要是基于我们正常使用的常用操作，能保证结果的正确，并不会对我们造成什么影响。如果非要规避ABA的场合，可以使用AtomicStampedReference，通过内部维护的一个时间戳来保证，比如上面线程2的操作，可理解为
修改A为B(2B)
修改B为A(3A)
此时线程1执行，获取到的A与当前内存中的3A就有差异了。
虽然能规避ABA问题，但是额外的开销势必会影响性能，而使用这种规避ABA问题的CAS实现，性能有没有使用synchronized高呢？可以根据实际业务场景和配置，做一个性能对比来权衡。
