AtomicInteger如何实现原子操作

在 java 中可以通过锁和循环 CAS 的方式来实现原子操作。AtomicInteger是通过循环 CAS 的方式来实现。

那么循环 CAS 是怎么保证原子性？

AtomicInteger atomicI = new AtomicInteger(0);
atomicI.incrementAndGet();

incrementAndGet的如下源码：

public final int incrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }
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;
    }
        public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
        public native int getIntVolatile(Object var1, long var2);

Unsafe 类提供 CAS 操作，CAS操作是本地方法（native），而且是不可改变（final）的。偏移量是干嘛用的呢？

public class AtomicInteger extends Number implements java.io.Serializable {
  // 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类中定义了一个value属性，并通过unsafe.objectFieldOffset方法获取到了这个属性在主存中设定的偏移量valueOffset。接着就可以在getAndIncrement方法中直接使用unsafe.getAndAddInt的方式，通过偏移量valueOffset将value属性的值加“1”。var5即为取到的变量，在以上代码中，getAndIncrement方法内部会不停的循环，比较value值和expect值，如果不相等，重新获取valuez，直到expect＝value = var5，更新value值为var5 + var4，此时unsafe.compareAndSwapInt方法执行成功。那么compareAndSwapInt(Object var1, long var2, int var4, int var5)方法又是如何保证原子性的呢？
compareAndSet利用JNI来完成CPU指令的原子操作。
反过来，为什么不直接通过JNI完成CPU指令的方式直接实现incrementAndGet（）呢
因为CPU指令只能实现简单的操作，Inter 处理器提供了很多 LOCK 前缀的指令来实现。比如位测试和修改指令 BTS，BTR，BTC，交换指令 XADD，CMPXCHG 和其他一些操作数和逻辑指令，比如 ADD（加），OR（或）等，被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。　
为什么要自旋循环呢？
为了保证读取到的value是最新的，并且循环执行直到成功。即使被其它线程修改了value值，仍可以获取到修改后的最新值，并且不断比较，直至修改成功。
CPU如何实现原子操作?
32 位 IA-32 处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。
1 处理器自动保证基本内存操作的原子性
首先处理器会自动保证基本的内存操作的原子性。处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。奔腾 6 和最新的处理器能自动保证单处理器对同一个缓存行里进行 16/32/64 位的操作是原子的，但是复杂的内存操作处理器不能自动保证其原子性，比如跨总线宽度，跨多个缓存行，跨页表的访问。但是处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。
2 使用总线锁保证原子性
第一个机制是通过总线锁保证原子性。如果多个处理器同时对共享变量进行读改写（i++ 就是经典的读改写操作）操作，那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致，举个例子：如果 i=1, 我们进行两次 i++ 操作，我们期望的结果是 3，但是有可能结果是 2。如下图

原因是有可能多个处理器同时从各自的缓存中读取变量 i，分别进行加一操作，然后分别写入系统内存当中。那么想要保证读改写共享变量的操作是原子的，就必须保证 CPU1 读改写共享变量的时候，CPU2 不能操作缓存了该共享变量内存地址的缓存。

处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个 LOCK＃信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住, 那么该处理器可以独占使用共享内存。
3 使用缓存锁保证原子性
第二个机制是通过缓存锁定保证原子性。在同一时刻我们只需保证对某个内存地址的操作是原子性即可，但总线锁定把 CPU 和内存之间通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。
频繁使用的内存会缓存在处理器的 L1，L2 和 L3 高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，在奔腾 6 和最近的处理器中可以使用“缓存锁定”的方式来实现复杂的原子性。所谓“缓存锁定”就是如果缓存在处理器缓存行中内存区域在 LOCK 操作期间被锁定，当它执行锁操作回写内存时，处理器不在总线上声言 LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时会起缓存行无效，在例 1 中，当 CPU1 修改缓存行中的 i 时使用缓存锁定，那么 CPU2 就不能同时缓存了 i 的缓存行。
但是有两种情况下处理器不会使用缓存锁定。第一种情况是：当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行（cache line），则处理器会调用总线锁定。第二种情况是：有些处理器不支持缓存锁定。对于 Inter486 和奔腾处理器, 就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。

缓存一致性机制怎么阻止同时被两个以上处理器修改呢？
在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里。一个处理器的缓存回写到内存会导致其他处理器的缓存无效。
value为什么要用valatile修饰呢？

Java 代码：
instance = new Singleton();//instance 是 volatile 变量
汇编代码：
0x01a3de1d: movb $0x0,0x1104800(%esi);
0x01a3de24: lock addl $0x0,(%esp);

为了保证可见性。即实现缓冲一致性机制。如果一个字段被声明成 volatile，java 线程内存模型确保所有线程看到这个变量的值是一致。有 volatile 变量修饰的共享变量进行写操作的时候会多第二行汇编代码，通过查 IA-32 架构软件开发者手册可知，lock 前缀的指令在多核处理器下会引发了两件事情。

将当前处理器缓存行的数据会写回到系统内存。
这个写回内存的操作会引起在其他 CPU 里缓存了该内存地址的数据无效。

循环 CAS 的缺点?
1 ABA 问题。
2 循环时间长开销大。
3 只能保证一个共享变量的原子操作。

参考文档：
https://www.jianshu.com/p/450925729f72
https://www.jianshu.com/p/df0585b61773
https://www.infoq.cn/article/ftf-java-volatile
https://www.infoq.cn/article/atomic-operation