前言
小伙伴们都知道，i++其实并非是原子性操作，在多线程环境下会有线程安全的问题，下面我们来写个测试demo来验证这条结论。
package com.sunyard.cas;
public class UsafeIncrDemo {
private static int i = 0;
public static void main(String[] args) throws InterruptedException {
Thread incrThread = new Thread(){
@Override
public void run() {
for(int k=0; k < 100000; k++){
i++;
}
}
};
incrThread.start();
for(int k=0; k < 100000; k++){
i++;
}
incrThread.join();
System.out.println(i);
/*
四次验证结果:
142089 133320 141347 141723
*/
}
}
通过上面的小例子我们可以发现每次计算的结果都有偏差。为什么会存在偏差呢？这是因为JMM将内存分为工作内存+主内存。我们的运算工作是在工作内存中进行，然后再将得到的值同步到主内存中。
通过上图我们可以看到，一开始主内存中i=0，此时线程A把i读到工作内存，并开始进行i++的运算，然后把运算结果i=1同步给主内存。但是因为整个过程并不是原子性的（线程A运算的过程中，线程B也可以进行运算），这时候线程A还没有来得及把计算后的值刷新回主内存，线程B就开始进行了i++的操作，此时线程B拿到的i的值为0，而不是线程A计算后的1，这样线程B经过运算，得到的结果也是1，这样就导致最终结果是1而不是我们期望的2，从而造成线程安全问题。
如何解决i++线程安全的问题呢？
1.synchronized锁
当我们对i++加了synchronized锁后，就可以保证它具有原子性，从而保证同一时刻只有一个线程能对i进行++操作，进而保证线程安全。
public class SafeIncrDemo {
private static int i = 0;
public static void main(String[] args) throws InterruptedException {
Object lock = new Object();
Thread incrThread = new Thread(){
@Override
public void run() {
for(int k=0; k < 100000; k++){
synchronized (lock){
i++;
}
}
}
};
incrThread.start();
for(int k=0; k < 100000; k++){
synchronized (lock){
i++;
}
}
incrThread.join();
System.out.println(i);
/*
四次验证结果:
200000 200000 200000 200000
*/
}
}
通过synchronized锁后，得到的结果跟预期结果相符。synchronized底层原理不是本篇文章的重点，后面会单出一篇文章来进行剖析。
2.通过J.U.C包下的AtomicInteger
package com.sunyard.cas;
import java.util.concurrent.atomic.AtomicInteger;
public class SafeIncrDemo {
private static AtomicInteger atomicInteger = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread incrThread = new Thread(){
@Override
public void run() {
for(int k=0; k < 100000; k++){
atomicInteger.getAndIncrement();
}
}
};
incrThread.start();
for(int k=0; k < 100000; k++){
atomicInteger.getAndIncrement();
}
incrThread.join();
System.out.println(atomicInteger.getAndIncrement());
/*
四次验证结果:
200000 200000 200000 200000
*/
}
}
ok,前面铺垫那么多，现在正式引入本文的重点：CAS,AtomicInteger就是基于CAS技术实现的。
什么是CAS
CAS，Compare and Swap即比较并替换。它是乐观锁思想的一种实现方式。
通过图我们可以看出CAS实现原理：CAS有三个操作数：内存值V、旧的预期值A、要修改的值B，当且仅当预期值A和内存值V相同时，将内存值修改为B并返回true，否则什么都不做并返回false。
通过AtomicInteger源码深入理解CAS
1.点开getAndIncrement()方法，我们会发现AtomicInteger调用了Unsafe的getAndInt()方法
2.跟进getAndAddInt方法
这时候我们是不是看到了熟悉的单词compareAndSwapInt，没错这里就是CAS的关键方法。
3.跟进compareAndSwapInt方法
哦嚯，这下懵逼了，这里是调用的native方法，再往下就是C语言的实现了。当然，作为一个喜欢研究(钻牛角尖)的程序猿，即使是native方法也不能阻挡我们求知的欲望。
4.去openJDK查到C语言相关实现
打开openJDK官网，找到对应的JDK版本，我这里以JDK1.8为例进行演示
小知识：JVM是规范，目前市面上主要有四种实现
1）Hotspot：最常用的jvm实现
2）JRocket：JRocket是BEA公司的JVM.使用WebLogic的用户,往往使用JRocket虚拟机.
3）J9：IBM公司的JVM
4）Harmony：IBM和Intel搞的开源JVM. IBM牵头,主力是Intel.
5.查看usafe.compareAndSwapInt在c语言中的实现
打开unsafe.cpp,找到compareAndSwapInt的实现
通过实现发现调用了Atomic的cmpxchg方法
6.继续跟进Atomic的cmpxchg方法
打开atomic.cpp,找到xmpxchg方法
我们入门java时老师总会告诉我们，java可以一次编译到处运行，其原理就是JVM在不同的平台有不同的实现。cmpxchg就是平台级的，在windows和linux系统上会有不同的实现方式，这里我们以linux平台为例进行代码跟进。
7.查看Atomic在linux平台上的实现
找到atomic_linux_x86.inline.hpp，找到cmpxchg方法
通过查阅资料，CAS的核心就是一条加了lock前缀的cmpxchg指令。
Atomic::cmpxchg解析：
os::is_MP() 即is multi-processor判断操作系统是否是多处理器
LOCK_IF_MP 即 lock if multi-processor 如果操作系统是多处理器，则加入lock前缀。这是一种优化手段，因为单处理器没有必要加lock。这里的lock指令在执行cmpxchg的时候会锁定一个北桥信号。
CAS优点和缺点
1.优点：
CAS是一种乐观锁，采用自旋的方式来等待其他线程完成工作。在竞争比较低且等待时间短的任务场景中表现优异。
2.缺点：
1）因为CAS采用自旋方式，而自旋是需要占用CPU资源的。
2）只能保持一个变量的原子操作
3） ABA问题
这里我来给小伙伴解释下什么是ABA问题，还是拿CAS流程图来讲
线程1在V==A这一步判断时，线程2把V变成了其他值后又变成了A，此时线程1是感知不到的，这就是ABA问题。
如何解决ABA问题呢？可以通过版本号来解决，每次操作都会把版本号递增，在判断V==A的时候也要判断版本号是否出现了变动。
CAS适用场景：
前面我们也提到了，CAS虽然会占用CPU资源，但是只在用户态就可以完成加锁的过程（不需要涉及到内核态）。那么线程数较少，竞争不激烈，等待时间短的场景就是CAS的最佳适用场景。小伙伴们get到了吗？
