【Java并发011】原理层面：CAS操作全解析

volatile关键字是Java51个关键字中用的比较少的一个，它是一个与多线程并发的关键字，但是实际开发中，一般不会用到，使用synchronize+wait()+notify()/notifyAll()或 lock+await()+signal()/signalAll() 组合就好了，但是我们现在学习JVM的知识，所有有必要知道volatile关键字及其底层原理，这里先上示例：

tip：该程序由《深入理解Java虚拟机》提出，在idea中运行，必须使用debug模式，不能用run运行。

字节码：

我们这里查看Test.class文件，一步步看每一个指令码，getstatic iconst_1 iadd putstatic 分析了为什么最后结果小于20万的原因，看似是从根本上搞懂了这个问题。

实际上，对于Java程序，即使是打印出.class文件，一条一条分析字节码也是不严谨的（因为是编译出来只有一条字节码指令，也不能说这条指令就是一个原子操作，即一条字节码不一定是一个不可拆分的原子操作），一条字节码指令在解释执行时，解释器将要运行许多行代码才能实现它的语义，如果是编译执行，一条字节码指令也可能转化成若干条本地机器码指令，这里是值得注意的。

问题1：为什么小于20万？
回答1：因为 i++；是一个三步骤操作，不是原子操作，要在多线程中安全，要同时保证原子性、可见性和有序性，即使使用volidate关键字，也只是一个保证可见性和有序性（合理使用volidate禁止指令重排），没保证原子性，三步骤操作可以被打断，处理方式是下面的使用原子类AtomInteger完成。

问题2：为什么使用原子类AtomInteger可以完成？
回答2：synchrOnized== for + if(cas线程安全判断)，在incrementAndGet()方法中使用 for循环 + if(cas判断)包裹，保证线程安全，所以最后等于20000，所以incrementAndGet()方法中的 for + if(cas线程安全判断) 保证了线程安全。

2.1 CAS三步操作+CAS与阻塞同步的对比+三种锁

2.1.1 CAS三步操作

首先要说一下，AtomicInteger类compareAndSet通过原子操作实现了CAS操作，最底层基于汇编语言实现。

简单说一下原子操作的概念，“原子”代表最小的单位，所以原子操作可以看做最小的执行单位，该操作在执行完毕前不会被任何其他任务或事件打断。

CAS是Compare And Set的一个简称，如下理解：

1. 已知当前内存里面的值current和预期要修改成的值new传入


2. 内存中AtomicInteger对象地址对应的真实值(因为有可能别修改)real与current对比，


3. 相等表示real未被修改过，是“安全”的，将new赋给real结束然后返回；不相等说明real已经被修改，结束并重新执行1直到修改成功

CAS相比Synchronized，避免了锁的使用，总体性能比Synchronized高很多.

2.1.2 CAS与内建锁比较

问题1：cas的两个应用？
回答1：cas的两个应用：lock里面 + AtomicInteger里面。

问题2：为什么lock比synchronized高效？
回答2：在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

2.1.3 Java三种锁

CAS（无锁操作，乐观锁策略）：使用CAS叫做比较交换来判断是否出现冲突，出现冲突就重试当前操作直到不冲突为止。

悲观锁（JDK1.6之前的内建锁）：假设每一次执行同步代码块均会产生冲突，所以当线程获取锁成功，会阻塞其他尝试获取该锁的线程。

乐观锁（Lock机制）：假设所有线程访问共享资源时不会出现冲突，既然不会出现冲突自然就不会阻塞其他线程。线程不会出现阻塞状态。

2.2 CAS的应用：AtomicInteger类中的compareAndSet()方法使用for+if(cas)保证线程安全

这里只要记住一点：
AtomicInteger类compareAndSet()方法使用for循环+if(cas)来保证线程安全就好了

2.2.1 从AtomicInteger类incrementAndGet()方法的源码出发，开启底层探索

compareAndSet典型使用为计数，如i++,++i,这里以i++为例：

public final int incrementAndGet() {
for (;;) {
//获取当前值
int current = get();
//设置期望值
int next = current + 1;
//调用Native方法compareAndSet，执行CAS操作
if (compareAndSet(current, next))
//成功后才会返回期望值，否则无线循环
return next;
}
}

incrementAndGet()解释：

1. incrementAndGet()方法由 “一个for + 一个if”组成，


2. 这个for就是自旋，现在还没有成功自增就循环自旋；


3. 这个if就是判断成功，current == real ，直接返回next(已经next=current+1，所以直接返回)


4. 小结：既看到了AtomicInteger类中的操作方法incrementAndGet()如何完成自旋代替阻塞同步，又看到了compareAndSet()方法如何使用CAS操作保证线程安全（就是一定要real==current才返回为true，从而保证安全）所以，synchrOnzied== for自旋 + if(CAS判断当前线程安全)

2.2.2 继续深入AtomicInteger类的compareAndSet方法

compareAndSet方法实现：

JDK文档对该方法的说明如下：如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。

public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

这里嵌入解释一下valueOffset变量，首先valueOffset的初始化在static静态代码块里面，代表相对起始内存地址的字节相对偏移量：

private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}

在生成一个AtomicInteger对象后，可以看做生成了一段内存，对象中各个字段按一定顺序放在这段内存中，字段可能不是连续放置的，

unsafe.objectFieldOffset(Field f)这个方法准确地告诉我"value"字段相对于AtomicInteger对象的起始内存地址的字节相对偏移量。

private volatile int value;

public AtomicInteger(int initialValue) {
value = initialValue;
}

public AtomicInteger() {
}

在这段程序中，value是一个volatile变量，不同线程对这个变量进行操作时具有可见性，修改与写入操作都会存入主存中，并通知其他cpu中该变量缓存行无效，保证了每次读取都是最新的值

2.2.3 继续深入native compareAndSwapInt()方法

找到sun.misc.Unsafe.java：

/**
* Atomically update Java variable to >x> if it is currently
* holding >expected>.
* @return >true> if successful
*/
public final native boolean compareAndSwapInt(Object o, long offset,int expected,int x);

2.2.4 继续深入UNSAFE_ENTRY()方法

继续查找unsafe.cpp,(http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/share/vm/prims/unsafe.cpp)：

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
UnsafeWrapper("Unsafe_CompareAndSwapInt");
oop p = JNIHandles::resolve(obj);
jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END

2.2.5 继续深入的Atomic::cmpxchg()

实现主要方法为Atomic::cmpxchg , 这个本地方法的最终实现在openjdk的如下位置：openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp（对应于windows操作系统，X86处理器）

// Adding a lock prefix to an instruction on MP machine
// VC++ doesn't like the lock prefix to be on a single line
// so we can't insert a label after the lock prefix.
// By emitting a lock prefix, we can define a label after it.
#define LOCK_IF_MP(mp) __asm cmp mp, 0 \
__asm je L0 \
__asm _emit 0xF0 \
__asm L0:

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
// alternative for InterlockedCompareExchange
int mp = os::is_MP();
__asm {
mov edx, dest
mov ecx, exchange_value
mov eax, compare_value
LOCK_IF_MP(mp)
cmpxchg dword ptr [edx], ecx
}
}

如上面源代码所示，用嵌入的汇编实现的, CPU指令是 cmpxchg，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀(tip：就是 LOCK_IF_MP(mp) 代码)。

金手指：对于LOCK_IF_MP(mp) 代码
如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀(lock cmpxchg).反之，如果程序是在单处理器上运行，就省略lock前缀(单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果).

lock前缀的作用说明：

1. 禁止该指令与之前和之后的读和写指令重排序;


2. 把写缓冲区中的所有数据刷新到内存中。

总的来说，Atomic（例如：AtomicInteger类）实现了高效无锁(tip：底层还是用到排它锁，就是多处理器下的lock前缀，不过底层处理比java层处理要快很多)与线程安全(volatile变量特性)，CAS一般适用于计数；

多线程编程也适用，多个线程执行AtomicXXX类下面的方法，当某个线程执行的时候具有排他性，在执行方法中不会被打断，直至当前线程完成才会执行其他的线程（上面的AtomicInteger类中incrementAndGet()方法使用CompareAndSet()方法来完成保证加一操作的线程安全性，取代synchronized同步阻塞）。

3.1 什么是ABA问题（理论解释,一图就好了）

3.2 代码重现ABA问题（代码，了解即可）

public class ABADemo {
private static AtomicReference> atomicReference = new AtomicReference>(100);
public static void main(String[] args) {
new Thread(() -> {
atomicReference.compareAndSet(100, 101);
atomicReference.compareAndSet(101, 100);
},"t1").start();

new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(atomicReference.compareAndSet(100, 2019) + "\t修改后的值:" + atomicReference.get());
},"t2").start();
}
}

输出结果：

true 修改后的值:2019

对于程序的解释：

1. CAS操作步骤一：初始值为100，


2. CAS操作步骤二：线程t1将100改成101，然后又将101改回100


3. CAS操作步骤三：线程t2先睡眠1秒，等待t1操作完成，然后t2线程将值改成2019，可以看到，线程2修改成功

3.3 ABA问题：原因、突破口、解决方式、源码支持

3.3.1 ABA问题的产生原因（重点）

根本原因：ABA问题产生的原因是传统的CAS仅仅对业务数值的比较，current==real，就是认为没有修改过，这样的比较条件是不充分的。

举例：对于 10 -> 11 ->10，仅仅比较数值，无法知道当前获取值是否已被修改过。

3.3.2 ABA问题：从原因到突破口再到解决方式（重点）

知道了ABA问题产生的原因，就知道解决这个问题的突破点：

核心原因：对于 10 -> 11 ->10，仅仅比较数值，无法知道当前获取值是否已被修改过。

突破点：在获取到数值的时候，要找到一个办法知道当前获取到的数值是否已被修改过。

JDK的处理办法：提供两个类，不仅比较数值，还有比较当前的数值是否被修改过，比如：

1. AtomicStampedReference使用int来记录版本号，表示当前数值是否被修改过（在current=real的条件下，版本号相同就是未被修改，版本号不同是已被修改）；


2. AtomicMarkableReference使用boolean来记录当前数值是否被修改过（在current=real的条件下，false就是未被修改，true是已被修改）。

3.3.3 ABA问题两个类的源码解析：不仅比较数值，还有比较当前的数值是否被修改过

1、AtomicStampedReference类源码解析

这里使用的是AtomicStampedReference的compareAndSet函数，这里面有四个参数：

compareAndSet(V expectedReference, V newReference, int expectedStamp, int newStamp)。

（1）第一个参数expectedReference：表示预期值。
（2）第二个参数newReference：表示要更新的值。
（3）第三个参数expectedStamp：表示预期的时间戳。
（4）第四个参数newStamp：表示要更新的时间戳。

这个compareAndSet方法到底是如何实现的，我们深入到源码中看看。

public boolean compareAndSet(V expectedReference, V newReference,
int expectedStamp, int newStamp) {
Pair> current = pair;
return expectedReference == current.reference && expectedStamp == current.stamp &&
((newReference == current.reference && newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}

可以看到，最后的返回值，同时比较数值和版本号

Pair类

private static class Pair> {
final T reference;
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static > Pair> of(T reference, int stamp) {
return new Pair>(reference, stamp);
}
}

casPair()方法

private boolean casPair(Pair> cmp, Pair> val) {
return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val);
}


连在一起看，如下图：

2、AtomicMarkableReference类源码解析

public boolean compareAndSet(V expectedReference,V newReference,
boolean expectedMark,boolean newMark) {
Pair> current = pair;
return
expectedReference == current.reference && expectedMark == current.mark &&
((newReference == current.reference && newMark == current.mark) ||
casPair(current, Pair.of(newReference, newMark)));
}

Pair类

private static class Pair> {
final T reference;
final boolean mark;
private Pair(T reference, boolean mark) {
this.reference = reference;
this.mark = mark;
}
static > Pair> of(T reference, boolean mark) {
return new Pair>(reference, mark);
}
}

casPair()方法

private boolean casPair(Pair> cmp, Pair> val) {
return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val);
}

连在一起看，如下图：

3.4 代码解释ABA问题两个类处理

3.4.1 AtomicStampedReference类代码解决ABA问题

要解决ABA问题，可以增加一个版本号，当内存位置V的值每次被修改后，版本号都加1。

AtomicStampedReference内部维护了对象值和版本号，在创建AtomicStampedReference对象时，需要传入初始值和初始版本号，当AtomicStampedReference设置对象值时，对象值以及状态戳都必须满足期望值，写入才会成功。

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicStampedReference;
public class ABADemo {
private static AtomicStampedReference> atomicStampedReference = new AtomicStampedReference>(100,1);
public static void main(String[] args) {
new Thread(() -> {
System.out.println("t1拿到的初始版本号:" + atomicStampedReference.getStamp());
//睡眠1秒，是为了让t2线程也拿到同样的初始版本号
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicStampedReference.compareAndSet(100, 101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
atomicStampedReference.compareAndSet(101, 100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
},"t1").start();
new Thread(() -> {
int stamp = atomicStampedReference.getStamp();
System.out.println("t2拿到的初始版本号:" + stamp);
//睡眠3秒，是为了让t1线程完成ABA操作
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("最新版本号:" + atomicStampedReference.getStamp());
System.out.println(atomicStampedReference.compareAndSet(100, 2019,stamp,atomicStampedReference.getStamp() + 1) + "\t当前 值:" + atomicStampedReference.getReference());
},"t2").start();
}
}

输出结果：

t1拿到的初始版本号:1
t2拿到的初始版本号:1
最新版本号:3
false 当前 值:100

对于这个程序的解释：

1. 初始值100，初始版本号1


2. 线程t1和t2拿到一样的初始版本号


3. 线程t1完成ABA操作，版本号递增到3


4. 线程t2完成CAS操作，最新版本号已经变成3，跟线程t2之前拿到的版本号1不相等，操作失败

由此可知，这里返回为false，表示已经被修改过，因为不仅比较数值，还有比较当前的数值是否被修改过，都满足才返回为true。

AtomicStampedReference可以给引用加上版本号，追踪引用的整个变化过程，如：A -> B -> C -> D - > A，通过AtomicStampedReference，我们可以知道，引用变量中途被更改了3次。

但是，有时候，我们并不关心引用变量更改了几次，只是单纯的关心是否更改过，所以就有了AtomicMarkableReference类，且看下文。

3.4.2 AtomicStampedReference类代码解决ABA问题

AtomicMarkableReference的唯一区别就是不再用int标识引用，而是使用boolean变量——表示引用变量是否被更改过

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicMarkableReference;
public class ABADemo2 {
private static AtomicMarkableReference> atomicMarkableReference = new AtomicMarkableReference>(100,false);
public static void main(String[] args) {
new Thread(() -> {
System.out.println("t1版本号是否被更改:" + atomicMarkableReference.isMarked());
//睡眠1秒，是为了让t2线程也拿到同样的初始版本号
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicMarkableReference.compareAndSet(100, 101,atomicMarkableReference.isMarked(),true);
atomicMarkableReference.compareAndSet(101, 100,atomicMarkableReference.isMarked(),true);
},"t1").start();
new Thread(() -> {
boolean isMarked = atomicMarkableReference.isMarked();
System.out.println("t2版本号是否被更改:" + isMarked);
//睡眠3秒，是为了让t1线程完成ABA操作
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("是否更改过:" + atomicMarkableReference.isMarked());
System.out.println(atomicMarkableReference.compareAndSet(100, 2019,isMarked,true) + "\t当前 值:" + atomicMarkableReference.getReference());
},"t2").start();
}
}

输出结果：

t1版本号是否被更改:false
t2版本号是否被更改:false
是否更改过:true
false 当前 值:100

对于这个程序的解释：

1. 初始值100，初始版本号未被修改 false


2. 线程t1和t2拿到一样的初始版本号都未被修改 false


3. 线程t1完成ABA操作，版本号被修改 true


4. 线程t2完成CAS操作，版本号已经变成true，跟线程t2之前拿到的版本号false不相等，操作失败

由此可知，这里返回为false，表示已经被修改过，因为不仅比较数值，还有比较当前的数值是否被修改过，都满足才返回为true。

4.1 CAS三步操作+CAS与内建锁比较+三种锁

4.1.1 CAS三步操作

首先要说一下，AtomicInteger类compareAndSet通过原子操作实现了CAS操作，最底层基于汇编语言实现。

简单说一下原子操作的概念，“原子”代表最小的单位，所以原子操作可以看做最小的执行单位，该操作在执行完毕前不会被任何其他任务或事件打断。

CAS是Compare And Set的一个简称，如下理解：

1. 已知当前内存里面的值current和预期要修改成的值new传入


2. 内存中AtomicInteger对象地址对应的真实值(因为有可能别修改)real与current对比，


3. 相等表示real未被修改过，是“安全”的，将new赋给real结束然后返回；不相等说明real已经被修改，结束并重新执行1直到修改成功

CAS相比Synchronized，避免了锁的使用，总体性能比Synchronized高很多.

4.1.2 CAS与内建锁比较

问题1：cas的两个应用？
回答1：cas的两个应用：lock里面 + AtomicInteger里面。

问题2：为什么lock比synchronized高效？
回答2：在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

4.1.3 三种锁

CAS（无锁操作，乐观锁策略）：使用CAS叫做比较交换来判断是否出现冲突，出现冲突就重试当前操作直到不冲突为止。

悲观锁（JDK1.6之前的内建锁）：假设每一次执行同步代码块均会产生冲突，所以当线程获取锁成功，会阻塞其他尝试获取该锁的线程。

乐观锁（Lock机制）：假设所有线程访问共享资源时不会出现冲突，既然不会出现冲突自然就不会阻塞其他线程。线程不会出现阻塞状态。

4.2 重点，CAS的应用：AtomicInteger类中的compareAndSet()方法使用for+if(cas)保证线程安全

4.2.1 AtomicInteger类中的compareAndSet()方法使用for+if(cas)保证线程安全

在Java的原子类，例如AtomicInteger类中，就有用到CAS操作，比如AtomicInteger类中的compareAndSet()方法，

return i++;三步操作如何原子化，在之前三步就完成了，仅仅只在等待合适的时机返回。
public final int incrementAndGet() {
for (;;) {
int current = get(); // 第一步，读取
int next = current + 1; // 第二步，计算+1,；第三步，赋值给next
if (compareAndSet(current, next)) // 三步都完成了，仅仅只在等待合适的时机返回。
return next;
}
}

问题：这个incrementAndGet()是在不使用synchronize的阻塞同步的前提下，完成多线程情况下，线程安全的自增操作？即 i++ 的硬件操作包括三步：从内存取出数据到寄存器，运算器中i++，从运算器中将数据放到内存中，既然不使用synchronized阻塞同步，那么这个AtomicInterger类中的incrementAndGet()方法如何在多线程情况下保证操作的原子性呢？
回答：synchrOnzied== for自旋 + if(CAS判断当前线程安全)，使用for自旋，if中使用CAS判断当前线程安全，等到线程安全的情况下，返回next(已经next=current+1，所以直接返回)

将if提上来知道两点，进一步理解 synchrOnzied== for自旋 +if(CAS判断当前线程安全)，将if判断提上来，我们就可以知道很多东西（源码中不把if提上来是因为把if提上来，包裹的大了，性能就变差了，和synchronized一样，包裹的大了，性能就差了）：

public final int incrementAndGet() {
for (;;) {
if (compareAndSet(current, next)){ // 源码中不把if提上来是因为把if提上来，包裹的大了，性能就变差了，和synchronized一样，包裹的大了，性能就差了
// 将if判断提上来，就是一个synchronized，这就很好理解
// 所以说： synchronzied == for自旋 + if(CAS判断当前线程安全)
// 将if提上来1，所以说：阻塞同步和cas同步独立相等，都是保证原子性：将if判断提上来，就是一个synchronized，这就很好理解
// 将if提上来2，为什么都是保证原子性？
// 1、一定要线程安全才能进来 cas和synchronized都可以保证，cas一定要current==real才能进来，synchronized一定要获取到同步锁才能进来
// 2、里面的不出去，外面的不能进来，cas这里return next;之前都没有改变数据，所以里面的没出去，外面的不能进来；synchronized也可以保证这一点，里面的不执行完不释放锁，外面的进不来
int current = get();
int next = current + 1;
return next;
}
}
}

将if提上来，所以说 “阻塞同步和cas同步独立相等，都是保证原子性”，将if判断提上来，就是一个synchronized，这就很好理解

public final int incrementAndGet() {
for (;;) {
if (compareAndSet(current, next)){
int current = get();
int next = current + 1;
return next;
}
}
}
等价
public final int incrementAndGet() {
synchronized(this){
int current = get();
int next = current + 1;
return next;
}
}
// 小结: cas不参与任何实际业务逻辑,
// cas仅仅返回true|false作为线程安全的判断依据，不参与实际逻辑,和synchronized一样

所有有如下表：

问题：为什么将if提上来，可以保证原子性？
回答：保证原子性就是两点：保证加锁才进入临界区、保证走完临界区代码才解锁。

1. 一定要线程安全才能进来 cas和synchronized都可以保证，cas一定要current==real才能进来，synchronized一定要获取到同步锁才能进来；


2. 里面的不出去，外面的不能进来，cas这里return next;之前都没有改变数据，所以里面的没出去，外面的不能进来；synchronized也可以保证这一点，里面的不执行完不释放锁，外面的进不来**
   所以，所有的cas包裹的都可以改写为synchronized包裹的，所有的synchronized包裹的都可以改写为cas包裹的。

4.2.2 CAS底层如何完成比较current和real的

底层使用用嵌入的汇编指令实现的, CPU指令是 cmpxchg，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀(tip：就是 LOCK_IF_MP(mp))。

问题：对于 LOCK_IF_MP(mp) 代码的解释？
回答：如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀(lock cmpxchg).反之，如果程序是在单处理器上运行，就省略lock前缀(单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果).

lock前缀的作用说明：

1. 禁止该指令与之前和之后的读和写指令重排序；


2. 把写缓冲区中的所有数据刷新到内存中。

4.3 ABA问题：原因+突破口+解决方式+源码

4.3.1 ABA问题的产生原因（背诵）

根本原因：ABA问题产生的原因是传统的CAS仅仅对业务数值的比较，current==real，就是认为没有修改过，这样的比较条件是不充分的。

举例：对于 10 -> 11 ->10，仅仅比较数值，无法知道当前获取值是否已被修改过。

4.3.2 ABA问题：从原因到突破口再到解决方式（背诵）

知道了ABA问题产生的原因，就知道解决这个问题的突破点：

核心原因：对于 10 -> 11 ->10，仅仅比较数值，无法知道当前获取值是否已被修改过。

突破点：在获取到数值的时候，要找到一个办法知道当前获取到的数值是否已被修改过。

问题：如何实现比较当前的数值是否被修改过？
回答：第一，记录版本号；第二，用boolean记录当前数值是否被修改过。
具体：JDK的中提供两个类，不仅比较数值，还有比较当前的数值是否被修改过，其中，

1. AtomicStampedReference使用int来记录版本号，表示当前数值是否被修改过（在current=real的条件下，版本号相同就是未被修改，版本号不同是已被修改）；


2. AtomicMarkableReference使用boolean来记录当前数值是否被修改过（在current=real的条件下，false就是未被修改，true是已被修改）。

4.3.3 源码解析：不仅比较数值，还有比较当前的数值是否被修改过，都满足才返回为true

这里返回为false，表示已经被修改过，因为不仅比较数值，还有比较当前的数值是否被修改过，都满足才返回为true。

4.4 CAS中的自旋会浪费大量的处理器资源（CPU） 简单来说就是太耗费时间

问题1：CAS是什么？
回答1：cas就是compare and swap，cas就是不断使用compare比较N和O， 一旦compare成功，就操作更改N，然后swap，N设置为V，不成功，返回N，不断compare。

问题2：辨析自旋和阻塞？
回答2：
自旋是线程失败后没有停止下来，还是在不停的尝试获取同步锁；
阻塞是线程获取锁失败后就停止下来，需要等时间过后或其他线程唤醒（计时阻塞+阻塞）。

问题3：举例说明自旋和阻塞
回答3：自旋与阻塞：举个栗子来说，当你开车到了一个十字路口时，这时发现亮的是红灯，那么这时的你就有两种选择，要么将车子直接熄火等待，要么踩住刹车等待；而这时的熄火和刹车就相当于阻塞和自旋，那么我们该如何去选择使用哪种处理方法呢？当又回到刚才的栗子，当你到达十字路口时发现，额的神呀，今天的红灯的等待时间竟然有半个小时，这时你二话不说将车子熄火，自己蒙头大睡来等待红灯；但是当你发现红灯只有10秒钟时，你就会选择踩住刹车来等待红灯；你这里的处理机制就是在不同的情况下，哪种方法使得车子耗油最少就选择哪个方法。又回到主题上，所以不能说自旋就一定会比阻塞的性能好。

自旋问题的处理，jdk使用自适应自旋
为了解决自旋存在的问题，CPU就采取了一种处理机制：自适应自旋（根据以往自旋等待时能否获取到锁，来动态调整自旋的时间（循环尝试数量））

自适应自旋和出现其实也是与现实生活相关的，再次回到上个栗子中，如果之前不熄火等到了绿灯，那么这次不熄火的时间就长一点，多等会也没事；如果之前不熄火没等待绿灯， 那么这次不熄火的时间就短一点。自适应自旋也是如此，如果在上一次自旋时获取到锁，则此次自旋时间稍微变长一点；如果在上一次自旋结束还没有获取到锁，此次自旋时间稍微短一点。

问题4：解释一下自适应自旋？
回答4：
如果在上一次自旋时获取到锁，多给一点机会，则此次自旋时间稍微变长一点；
如果在上一次自旋结束还没有获取到锁，少给一点机会，此次自旋时间稍微短一点。

4.5 CAS操作的公平性问题

问题1：公平模式和非公平模式？
回答1：

1. 公平模式 比如一个锁被很多线程等待是时，锁会选择等待时间最长的线程访问它的临界资源，可以和队列类比一下理解为先到先得原则（lock锁）它就是公平的。


2. 非公平模式 而当一个锁是可以被后来的线程抢占时，它就是非公平性的，比如内建锁（饥饿问题：由于访问权限总是分配给了其他线程，而造成一个或多个线程被饿死的现象）。

自旋也是一种不公平的模式：因为处于阻塞状态的线程无法立刻竞争被释放的锁，而处于自旋状态的线程很有可能先获取到锁。

问题2：谈一谈你对公平锁的理解？cas的自旋操作是公平的吗？
回答2：

1. 第一，公平锁是没有意义的，强制实现公平锁只会降低效率，非公平锁可以得到更好的效率；这也就是为什么synchronized重量锁是非公平的，cas的自旋操作也是非公平的，lock默认是非公平的，只是可以实现公平锁，所以说，从jdk源码，公平锁只是个可选项，并不是一个默认推荐项。


2. 第二，公平锁的含义：每次执行等待时间最长的那个线程，底层必须使用队列来实现


3. 第三，公平锁的实现：synchronized重量锁是非公平的，cas的自旋操作也是非公平的，lock默认是非公平的，只是可以实现公平锁。


4. 第四，lock是如何使用队列来实现公平锁的：详见另外一篇博客。

原理层面：CAS操作全解析，完成了。

天天打码，天天进步！！！