管理

Java并发编程之CAS

PS：一个CPU缓存的错误认识：

错误想法：那就是不使用缓存直接操作内存，cpu在读取数据操作数据再写数据的过程，cpu也有短暂的缓存数据的，这样也存在一致性问题（可见性，顺序）。
实际情况：cpu直接读和写都是原子性的，其次通过缓存锁的形式（还有总线锁的形式），保证了同一块内存被修改的过程中，其他cpu（或者线程）不能使用该内存。

Java8中CAS的增强

JAVA中CAS原理详解

1，锁机制的问题

在JDK 5之前Java语言是靠synchronized关键字保证同步的，这会导致有锁

锁机制存在以下问题：

1，在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
2，一个线程持有锁会导致其它所有需要此锁的线程挂起。
3，如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。
4，volatile是不错的机制，但是volatile不能保证原子性。因此对于同步最终还是要回到锁机制上来。

独占锁是一种悲观锁，synchronized就是一种独占锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。

而另一个更加有效的锁就是乐观锁。

所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。

乐观锁用到的机制就是CAS，Compare and Swap。

2，什么是CAS

1，在java语言之前，硬件厂商老早就在芯片中加入了大量直至并发操作的原语，从而在硬件层面提升效率。在intel的CPU中，使用cmpxchg指令。
2，随着java不断的发展,Java本地方法(JNI)的出现，使得java程序越过JVM直接调用本地方法提供了一种便捷的方式，
3，在Doug Lea提供的cucurenct包中，CAS理论是它实现整个java包的基石。

CAS（Compare and swap）比较和替换是设计并发算法时用到的一种技术。

简单来说，比较和替换是使用一个期望值和一个变量的当前值进行比较，如果当前变量的值与我们期望的值相等，就使用一个新值替换当前变量的值。

CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。
如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。

无论哪种情况，它都会在 CAS 指令之前返回该位置的值。（在 CAS 的一些特殊情况下将仅返回 CAS 是否成功，而不提取当前值。）
CAS 有效地说明了“我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。”

通常将 CAS 用于同步的方式是从地址 V 读取值 A，执行多步计算来获得新值 B，然后使用 CAS 将 V 的值从 A 改为 B。如果 V 处的值尚未同时更改，则 CAS 操作成功。

类似于 CAS 的指令允许算法执行读-修改-写操作，而无需害怕其他线程同时 修改变量，因为如果其他线程修改变量，那么 CAS 会检测它（并失败），算法可以对该操作重新计算。

3，CAS原理

利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法。
其它原子操作都是利用类似的特性完成的。而整个J.U.C都是建立在CAS之上的，因此对于synchronized阻塞算法，J.U.C在性能上有了很大的提升。
CAS通过调用JNI的代码实现的。
(JNI:Java Native Interface为JAVA本地调用，允许java调用其他语言。)
而compareAndSwapInt就是借助C来调用CPU底层指令实现的。

下面从分析比较常用的CPU（intel x86）来解释CAS的实现原理。

下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码：

public final native boolean compareAndSwapInt(Object o, long offset,int expected,int x);

可以看到这是个本地方法调用。

这个本地方法在openjdk中依次调用的c++代码为：

unsafe.cpp，atomic.cpp和atomicwindowsx86.inline.hpp。

这个本地方法的最终实现在openjdk的如下位置：

openjdk-7-fcs-src-b147-27jun2011openjdkhotspotsrcoscpuwindowsx86vm atomicwindowsx86.inline.hpp
（对应于windows操作系统，X86处理器）。

下面是对应于intel 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
  }
}

如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。

如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（lock cmpxchg）。
反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）。

intel的手册对lock前缀的说明如下：

1,确保对内存的读-改-写操作原子执行。
在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。

从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：
如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），
并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。

由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。
这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。

2,禁止该指令与之前和之后的读和写指令重排序。
3,把写缓冲区中的所有数据刷新到内存中。

4，关于CPU的锁有如下3种：

4.1，处理器自动保证基本内存操作的原子性

首先处理器会自动保证基本的内存操作的原子性。
处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。
（ps:这里说的不能同时访问应该是：读的时候不能写；写的时候不能读；两个不能同时在写。）

奔腾6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操作是原子的，
但是复杂的内存操作处理器不能自动保证其原子性，比如跨总线宽度，跨多个缓存行，跨页表的访问。

但是处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。

4.2，使用总线锁保证原子性

第一个机制是通过总线锁保证原子性。
如果多个处理器同时对共享变量进行读改写（i++就是经典的读改写操作）操作，
那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致，
举个例子：如果i=1,我们进行两次i++操作，我们期望的结果是3，但是有可能结果是2
原因是有可能多个处理器同时从各自的缓存中读取变量i，分别进行加一操作，然后分别写入系统内存当中。

那么想要保证读改写共享变量的操作是原子的，就必须保证CPU1读改写共享变量的时候，CPU2不能操作缓存了该共享变量内存地址的缓存。
处理器使用总线锁就是来解决这个问题的。
所谓总线锁就是使用处理器提供的一个LOCK＃信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住,那么该处理器可以独占使用共享内存。

4.3，使用缓存锁保证原子性

第二个机制是通过缓存锁定保证原子性。
在同一时刻我们只需保证对某个内存地址的操作是原子性即可，
但总线锁定把CPU和内存之间通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，
所以总线锁定的开销比较大，最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。

频繁使用的内存会缓存在处理器的L1，L2和L3高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，
在奔腾6和最近的处理器中可以使用“缓存锁定”的方式来实现复杂的原子性。
所谓“缓存锁定”就是如果缓存在处理器缓存行中内存区域在LOCK操作期间被锁定，
当它执行锁操作回写内存时，处理器不在总线上声言LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，
因为缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据，（当其他处理器回写已被锁定的缓存行的数据时会见缓存行无效）
如：当CPU1修改缓存行中的 i 时使用缓存锁定，那么CPU2就不能同时缓存了 i 的缓存行。

但是有两种情况下处理器不会使用缓存锁定。
第一种情况是：当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行（cache line），则处理器会调用总线锁定。
第二种情况是：有些处理器不支持缓存锁定。对于Inter486和奔腾处理器,就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。
以上两个机制我们可以通过Inter处理器提供了很多LOCK前缀的指令来实现。
比如位测试和修改指令BTS，BTR，BTC，交换指令XADD，CMPXCHG
和其他一些操作数和逻辑指令，比如ADD（加），OR（或）等，被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。

5，CAS缺点

CAS虽然很高效的解决原子操作，但是CAS仍然存在三大问题：

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

ABA问题。

因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，
但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。
ABA问题的解决思路就是使用版本号。
在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。
从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。
这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

循环时间长开销大。

自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，
pause指令有两个作用，
第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

只能保证一个共享变量的原子操作。

当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，
但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。
比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。
从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

6，concurrent包的实现

由于java的CAS同时具有 volatile 读和volatile写的内存语义，因此Java线程之间的通信现在有了下面四种方式：

1，A线程写volatile变量，随后B线程读这个volatile变量。
2，A线程写volatile变量，随后B线程用CAS更新这个volatile变量。
3，A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。
4，A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键

（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，

因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。

同时，volatile变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。

如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：

首先，声明共享变量为volatile；
然后，使用CAS的原子条件更新来实现线程之间的同步；
同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。

AQS，非阻塞数据结构和原子变量类（Java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，

而concurrent包中的高层类又是依赖于这些基础类来实现的。

从整体来看，concurrent包的实现示意图如下：

参考文档：

http://www.blogjava.NET/xylz/archive/2010/07/04/325206.html

http://blog.hesey.Net/2011/09/resolve-aba-by-atomicstampedreference.html

http://www.searchsoa.com.cn/showcontent_69238.htm

http://ifeve.com/atomic-operation/

http://www.infoq.com/cn/articles/Java-memory-model-5

补充：

谈到并发，不得不谈ReentrantLock；而谈到ReentrantLock，不得不谈AbstractQueuedSynchronizer（AQS）！

Java并发之AQS详解

AQS的原理浅析

ps：以上理论性概念太多，涉及cpu，有点似懂非懂

深入浅出CAS

1，前言

CAS（Compare and Swap），即比较并替换。

CAS的思想很简单：

三个参数，一个当前内存值V、旧的预期值A、即将更新的值B，当且仅当预期值A和内存值V相同时，将内存值修改为B并返回true，否则什么都不做，并返回false。

2，一个`n++`的问题。

public class Case {
    public volatile int n;
    public void add() {
        n++;
    }
}

通过javap -verbose Case看看add方法的字节码指令

public void add();
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0       
         1: dup           
         2: getfield      #2                  // Field n:I
         5: iconst_1      
         6: iadd          
         7: putfield      #2                  // Field n:I
        10: return

n++被拆分成了几个指令：

执行getfield拿到原始n；
执行iadd进行加1操作；
执行putfield写把累加后的值写回n；

通过volatile修饰的变量可以保证线程之间的可见性，但并不能保证这3个指令的原子执行，

在多线程并发执行下，无法做到线程安全，得到正确的结果，那么应该如何解决呢？

3，如何解决

在add方法加上synchronized修饰解决。

public class Case {
    public volatile int n;
    public synchronized void add() {
        n++;
    }
}

这个方案当然可行，但是性能上差了点，还有其它方案么？

再来看一段代码

public int a = 1;
public boolean compareAndSwapInt(int b) {
    if (a == 1) {
        a = b;
        return true;
    }
    return false;
}

如果这段代码在并发下执行，会发生什么？

假设线程1和线程2都过了a==1的检测，都准备执行对a进行赋值，结果就是两个线程同时修改了变量a，显然这种结果是无法符合预期的，无法确定a的最终值。

解决方法也同样暴力，在compareAndSwapInt方法加锁同步，变成一个原子操作，同一时刻只有一个线程才能修改变量a。

除了低性能的加锁方案，我们还可以使用JDK自带的CAS方案，在CAS中，比较和替换是一组原子操作，不会被外部打断，且在性能上更占有优势。

下面以AtomicInteger的实现为例，分析一下CAS是如何实现的。

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  //ps:初始化value在内存的位置。
                (AtomicInteger.class.getDeclaredField("value"));//有个疑问静态初始化是在实例化之前，怎么获取到位置的？除非这只是对象的相对位置。
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;
    public final int get() {return value;}
}

1，Unsafe，是CAS的核心类，由于Java方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe相当于一个后门，基于该类可以直接操作特定内存的数据。
2，变量valueOffset，表示该变量值在内存中的偏移地址，因为Unsafe就是根据内存偏移地址获取数据的。
3，变量value用volatile修饰，保证了多线程之间的内存可见性。

看看AtomicInteger如何实现并发下的累加操作：

public final int getAndAdd(int delta) {    
    return unsafe.getAndAddInt(this, valueOffset, delta);//ps: delta表示变化量
}

//unsafe.getAndAddInt
public final int getAndAddInt(Object var1, long var2, int var4) { //ps: v2是value值所在内存位置，v4是变化量
    int var5;
    do {
        var5 = this.getIntVolatile(var1, var2);//ps: v5是当前value的值
    } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));//ps: 这里是原子的，判断的同时还计算修改值。
    return var5;
}

假设线程A和线程B同时执行getAndAdd操作（分别跑在不同CPU上）：(ps:下面成立，假设value=3,变化量为-1）

1，AtomicInteger里面的value原始值为3，即主内存中AtomicInteger的value为3，根据Java内存模型，线程A和线程B各自持有一份value的副本，值为3。
2，线程A通过getIntVolatile(var1, var2)拿到value值3，这时线程A被挂起。
3，线程B也通过getIntVolatile(var1, var2)方法获取到value值3，运气好，线程B没有被挂起，并执行compareAndSwapInt方法比较内存值也为3，成功修改内存值为2。
4，这时线程A恢复，执行compareAndSwapInt方法比较，发现自己手里的值(3)和内存的值(2)不一致，说明该值已经被其它线程提前修改过了，那只能重新来一遍了。
5，重新获取value值，因为变量value被volatile修饰，所以其它线程对它的修改，线程A总是能够看到，线程A继续执行compareAndSwapInt进行比较替换，直到成功。

PS:

上面3的意思是，B执行compareAndSwapInt方法，首先判断先前获取（值3）和现在内存（值3）是否一致，如果一致就计算然后修改（3-1=2 -> value=2)。
上面4的意思是，A执行compareAndSwapInt方法，首先判断先前获取（值3）和现在内存（值2）是否一致，不一致，从新获取，再判断执行，直到一致再计算修改。

为什么要获取，再原子性去，判断，计算，修改呢？这和使用锁的区别在哪里？

这就涉及到锁的弊端（其他线程挂起，上下文切换延时，锁获取释放也是消耗资源）。CAS应该只是cpu原子性操作。

那为什么不直接原子性，判断计算修改呢？

因为不提前获取，那么就不知道是基于哪个期望值和当前值进行比较（每个线程执行一次就会得到一个基准值（也即期望值））。

为什么不将获取也放到原子性操作里面呢？

都是原子性操作，那么就是悲观锁了，一定出现竞争错误数据了，效率也低了。

正如前面说的那样CAS是乐观锁，更加希望是在没有竞争的情况下运行，这样每次得到正确值。这样就不需要重复获取和判断了。

还有一种可能CPU的指令，cmpxchg(x, addr, e)的三个参数。x表示变化量；addr表示当前值的地址；e表示期望值；此指令并不能保证包括获取期望值整体是原子性的。

整个过程中，利用CAS保证了对于value的修改的并发安全，继续深入看看Unsafe类中的compareAndSwapInt方法实现。

public final native boolean compareAndSwapInt(Object paramObject, long paramLong, int paramInt1, int paramInt2);

Unsafe类中的compareAndSwapInt，是一个本地方法，该方法的实现位于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

先想办法拿到变量value在内存中的地址。
通过Atomic::cmpxchg实现比较替换，其中参数x是即将更新的值，参数e是原内存的值。

如果是Linux的x86，Atomic::cmpxchg方法的实现如下：

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;
}

看到这汇编，内心崩溃:

__asm__表示汇编的开始
volatile表示禁止编译器优化
LOCK_IF_MP是个内联函数

#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "

Window的x86实现如下：

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
    int mp = os::isMP(); //判断是否是多处理器
    _asm {
        mov edx, dest
        mov ecx, exchange_value
        mov eax, compare_value
        LOCK_IF_MP(mp)
        cmpxchg dword ptr [edx], ecx
    }
}

// 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:

LOCK_IF_MP根据当前系统是否为多核处理器决定是否为cmpxchg指令添加lock前缀。

如果是多处理器，为cmpxchg指令添加lock前缀。
反之，就省略lock前缀。（单处理器会不需要lock前缀提供的内存屏障效果）

intel手册对lock前缀的说明如下：

1,确保后续指令执行的原子性。
  在Pentium及之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其它处理器暂时无法通过总线访问内存，很显然，这个开销很大。
  在新的处理器中，Intel使用缓存锁定来保证指令执行的原子性，缓存锁定将大大降低lock前缀指令的执行开销。

2,禁止该指令与前面和后面的读写指令重排序。
3,把写缓冲区的所有数据刷新到内存中。

上面的第2点和第3点所具有的内存屏障效果，保证了CAS同时具有volatile读和volatile写的内存语义。

4，CAS缺点

CAS存在一个很明显的问题，即ABA问题。
问题：如果变量V初次读取的时候是A，并且在准备赋值的时候检查到它仍然是A，那能说明它的值没有被其他线程修改过了吗？

如果在这段期间曾经被改成B，然后又改回A，那CAS操作就会误认为它从来没有被修改过。
针对这种情况，java并发包中提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。

posted @ 2018-04-12 20:25 假程序猿阅读(459) 评论(0) 编辑收藏举报

刷新页面返回顶部

∝∝∝ξ══════════════════◤

Java并发编程之CAS

JAVA中CAS原理详解

1，锁机制的问题

2，什么是CAS

3，CAS原理

下面从分析比较常用的CPU（intel x86）来解释CAS的实现原理。

4，关于CPU的锁有如下3种：

5，CAS缺点

6，concurrent包的实现

深入浅出CAS

1，前言

2，一个`n++`的问题。

3，如何解决

4，CAS缺点

公告

∝∝∝ξ══════════════════◤

Java并发编程之CAS

JAVA中CAS原理详解

1，锁机制的问题

2，什么是CAS

3，CAS原理

下面从分析比较常用的CPU（intel x86）来解释CAS的实现原理。

4，关于CPU的锁有如下3种：

5，CAS缺点

6，concurrent包的实现

深入浅出CAS

1，前言

2，一个n++的问题。

3，如何解决

4，CAS缺点

公告

2，一个`n++`的问题。