CAS乐观锁
1.1 思考
看下⾯代码进⾏思考，此时number前⾯是加了volatile关键字修饰的，volatile不保证原⼦性，那么使⽤AtomicInteger是如何保证原⼦性的？这⾥的原理是什么？CAS
class MyData {
volatile int number = 0;
AtomicInteger atomicInteger=new AtomicInteger();
public void addPlusPlus(){
number++;
}
public void addAtomic(){
atomicInteger.getAndIncrement();
}
public void setTo60() {
this.number = 60;
}
}
CAS的全称为Compare-And-Swap，⽐较并交换，是⼀种很重要的同步思想。它是⼀条CPU并发原语。
它的功能是判断主内存某个位置的值是否为跟期望值⼀样，相同就进⾏修改，否则⼀直重试，直到⼀致为⽌。这个过程是原⼦的。
看下⾯这段代码，思考运⾏结果是
/**
* CAS的全称为Compare-And-Swap，比较并交换，是一种很重要的同步思想。它是一条CPU并发原语。
* 它的功能是判断主内存某个位置的值是否为跟期望值一样，相同就进行修改，否则一直重试，直到一致为止。这个过程是原子的。
*/
public class CASDemo {
public static void main(String[] args) {
AtomicInteger atomicInteger = new AtomicInteger(5);
//CAS操作
System.out.println(atomicInteger.compareAndSet(5, 2000)+"\t最终值:"+ atomicInteger.get());
System.out.println(atomicInteger.compareAndSet(5, 1024)+"\t最终值:"+ atomicInteger.get());
}
}
第⼀次修改，期望值为5，主内存也为5，修改成功，为2020。第⼆次修改，期望值为5，主内存为2020，修改失败，需要重新获取主内存的值 。
查看AtomicInteger.getAndIncrement() ⽅法，发现其没有加 synchronized 也实现了同步。这是为什么？
native：本地方法是C语言编写的，Unsafe这个类的几乎全是native方法，也就是说这个类是和电脑硬件打交道的。
C语言是可以直接操作计算机内存地址的，JAVA本身是不可以直接操作，但是Java中这个Unsafe类是可以直接操作计算机中的内存地址和CPU。
CAS并发原语体现在JAVA语⾔中就是sum.misc.Unsafe类中的各个⽅法。看⽅法源码，调⽤UnSafe类中的CAS⽅法，JVM会帮我们实现出CAS汇编指令。这是⼀种完全依赖于硬件的功能，通过它实现了原⼦操作。再次强调，由于CAS是⼀种系统原语，原语属于操作系统⽤语范畴，是由若⼲条指令组成的，⽤于完成某个功能的⼀个过程，并且原语的执⾏是连续的，在执⾏过程中不允许被中断，也就是说CAS是⼀条CPU的原⼦指令，不会造成所谓的数据不⼀致问题。
1.2 动画演示
乐观锁：不加锁，假设没有冲突去完成某项操作，如果因为冲突失败就重试，直到成功为止。其实现方式有一种比较典型的就是Compare and Swap( CAS )。
CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。
更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。
这样说或许有些抽象，我们来看一个例子：
1、 在内存地址V当中，存储着值为10的变量；
2、 此时线程1想要把变量的值增加1对线程1来说，旧的预期值A=10，要修改的新值B=11；
3、 在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11；
4、 线程1开始提交更新，首先进行A和地址V的实际值比较（Compare），发现A不等于V的实际值，提交失败；
5、 线程1重新获取内存地址V的当前值，并重新计算想要修改的新值此时对线程1来说，A=11，B=12这个重新尝试的过程被称为自旋；
6、 这一次比较幸运，没有其他线程改变地址V的值线程1进行Compare，发现A和地址V的实际值是相等的；
7、 线程1进行SWAP，把地址V的值替换为B，也就是12；
从思想上来说，Synchronized属于悲观锁，悲观地认为程序中的并发情况严重，所以严防死守。CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去尝试更新。
1.3 CAS底层原理
AtomicInteger内部的重要参数
1. Unsafe
是CAS的核⼼类，由于Java⽅法⽆法直接访问底层系统，需要通过本地（native）⽅法来访问，Unsafe相当于⼀个后门，基于该类可以直接操作特定内存的数据。Unsafe类存在于sum.misc包中，其内部⽅法操作可以像C的指针⼀样直接操作内存，因此Java中CAS操作的执⾏依赖于Unsafe类的⽅法。
注意Unsafe类中的所有⽅法都是native修饰的，也就是说Unsafe类中的⽅法都直接调⽤操作系统底层资源执⾏相应任务
2. 变量valueOffset，表示该变量值在内存中的偏移地址，因为Unsafe就是根据内存偏移地址获取数据的。
3. 变量value⽤volatile修饰，保证了多线程之间的内存可⻅性。
本地方法native想和计算机C语言打交道，他们中间要通过Java和C语言交互的规范，这个规范叫JNI（Java Native Interface）
AtomicInteger.getAndIncrement() 调⽤了 Unsafe.getAndAddInt() ⽅法。 Unsafe 类的⼤部分⽅法都是 native 的，⽤来像C语⾔⼀样从底层操作内存。
C语句代码JNI，对应java⽅法 public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5)
下面这段代码不是C语言代码，而是C语言中的.h头文件里面的一个接口说明的代码
//JNIENV *env：C语言的一个指针，JNI环境指针，这个指针不是我们这边提供的
//jobject unsafe：不安全类对象，代表的就是我们java中的Unsafe类
//jlong obj：obj就是上面Unsafe.compareAndSwapInt方法的第一个入参对象的地址值
//jlong offset，jint e,jint x：依次对应compareAndSwapInt方法的入参
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jlong obj, jlong offset,jint e, jint x))
UnsafeWrapper("Unsafe_CompareAndSwapInt");
oop p = JNIHandles::resolve(obj);//c语言中根据地址获取对象
jint* addr = (jint *)index_oop_from_field_offset_long(p, offset);//根据对象和属性偏移量获取对应属性在物理内存中的真实地址
return (jint)(Atomic::cmpxchg(x,addr,e))==e;
UNSAFE_END
//先想办法拿到变量value在内存中的地址addr。
//通过Atomic::cmpxchg实现⽐较替换，其中参数x是即将更新的值，参数e是原内存的值。
这个⽅法的var1和var2，就是根据对象和偏移量得到在主内存的快照值var5。然后 compareAndSwapInt ⽅法通过var1和var2得到当前主内存的实际值。如果这个实际值跟快照值相等，那么就更新主内存的值为var5+var4。如果不等，那么就⼀直循环，⼀直获取快照，⼀直对⽐，直到实际值和快照值相等为⽌。
参数介绍
- var1 AtomicInteger对象本身
- var2 该对象属性value值的引⽤地址
- var4 需要变动的数量
- var5 是通过var1和var2，根据对象和偏移量得到在主内存的快照值var5
⽐如有A、B两个线程，⼀开始都从主内存中拷⻉了原值为3，A线程执⾏到 var5=this.getIntVolatile ，即var5=3。此时A线程挂起，B修改原值为4，B线程执⾏完毕，由于加了volatile，所以这个修改是⽴即可⻅的。A线程被唤醒，执⾏ this.compareAndSwapInt() ⽅法，发现这个时候主内存的值不等于快照值3，所以继续循环，重新从主内存获取。
CAS + voliate 实现乐观锁
1.4 CAS缺点
CAS实际上是⼀种⾃旋锁
- 1. CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。 - 2. 不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证多个共享变量或整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。 -
- 引出了ABA问题。
1.5 CAS会导致"ABA问题"
所谓ABA问题，就是CAS算法实现需要取出内存中某时刻的数据并在当下时刻⽐较并替换，这⾥存在⼀个时间差，那么这个时间差可能带来意想不到的问题。
⽐如，⼀个线程B 从内存位置Value中取出2，这时候另⼀个线程A 也从内存位置Value中取出2，并且线程A 进⾏了⼀些操作将值变成了5，然后线程A ⼜再次将值变成了2，这时候线程B 进⾏CAS操作发现内存中仍然是2，然后线程B 操作成功。
尽管线程B的CAS操作成功，但是不代表这个过程就是没有问题的。
- 有这样的需求，⽐如CAS，只注重头和尾，只要⾸尾⼀致就接受。
- 但是有的需求，还看重过程，中间不能发⽣任何修改，这就引出了 AtomicStampedReference 原⼦标记引⽤。
先看AtomicReference
AtomicReference原⼦引⽤
AtomicInteger 对整数进⾏原⼦操作，如果是⼀个POJO呢？可以⽤ AtomicReference 来包装这个POJO，使其操作原⼦化。
public class AtomicReferenceDemo {
public static void main(String[] args) {
User user1 = new User("Jack",25);
User user2 = new User("Tom",21);
AtomicReference<User> atomicReference = new AtomicReference<>();
atomicReference.set(user1);
//CAS操作
System.out.println(atomicReference.compareAndSet(user1,user2)+"\t"+atomicReference.get()); // true
//CAS操作
System.out.println(atomicReference.compareAndSet(user1,user2)+"\t"+atomicReference.get()); //false
}
}
原理：
和AtomicInteger类似，底层利用unsafe.compareAndSwapObject
ABA问题的解决(AtomicStampedReference 类似于时间戳)
ThreadA 100 1 2020 2
ThreadB 100 1 111 2 100 3
线程A获取变量100，此时版本号为1，线程B也获取变量100，版本号为1，然后更新为111，此时版本号为2，之后又将变量更新回100，但是此时版本号已经是3了，虽然值还是100，这时线程A拿着版本号1的变量100想更新是不会成功的。
使⽤AtomicStampedReference 类可以解决ABA问题。这个类维护了⼀个“版本号”Stamp，在进⾏CAS操作的时候，不仅要⽐较当前值，还要⽐较版本号。只有两者都相等，才执⾏更新操作。
解决ABA问题的关键⽅法：
参数说明：
- V expectedReference, 预期值引⽤
- V newReference, 新值引⽤
- int expectedStamp， 预期值时间戳、版本号
- int newStamp, 新值时间戳 、版本号
真正进行CAS比较的时候，就像比较一个普通对象一样：
效果演示：
/**
* ABA问题
*/
public class ABADemo {
static AtomicReference<Integer> atomicReference = new AtomicReference<>(100);
//带有时间戳的原子引用 (共享内存值100， 版本号为1)
static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(100, 1);
public static void main(String[] args) {
System.out.println("========ABA问题的产生=========");
new Thread(()->{
//CAS
atomicReference.compareAndSet(100, 111);
//CAS
atomicReference.compareAndSet(111, 100);
}, "t1").start();
new Thread(()->{
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
//CAS
System.out.println(atomicReference.compareAndSet(100, 2020) +"\t"+atomicReference.get());
}, "t2").start();
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("=========ABA问题的解决===========");
new Thread(()->{
//获取第一次的版本号
int stamp = atomicStampedReference.getStamp();
System.out.println(Thread.currentThread().getName()+"\t第一次版本号"+ stamp);
//CAS
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicStampedReference.compareAndSet(
100,
111,
atomicStampedReference.getStamp(),
atomicStampedReference.getStamp()+1
);
System.out.println(Thread.currentThread().getName()+"\t第二次版本号："+ atomicStampedReference.getStamp());
//CAS
atomicStampedReference.compareAndSet(
111,
100,
atomicStampedReference.getStamp(),
atomicStampedReference.getStamp()+1
);
System.out.println(Thread.currentThread().getName()+"\t第三次版本号："+ atomicStampedReference.getStamp());
}, "t3").start();
new Thread(()->{
//获取第一次的版本号
int stamp = atomicStampedReference.getStamp();
System.out.println(Thread.currentThread().getName()+"\t第一次版本号"+ stamp);
//CAS
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
boolean result = atomicStampedReference.compareAndSet(
100,
2020,
stamp,
stamp + 1
);
System.out.println(
Thread.currentThread().getName()
+"\t修改是否成功："+result
+"\t当前最新的版本号："+atomicStampedReference.getStamp()
+"\t当前最新的值："+atomicStampedReference.getReference()
);
}, "t4").start();
}
}
