目录

• 一、CAS机制简介
• 1.1、悲观锁和乐观锁更新数据方式
• 1.2、什么是CAS机制
• 1.3、CAS与sychronized比较
• 1.4、Java中都有哪些地方应用到了CAS机制呢?
• 1.5、CAS 实现自旋锁
• 1.6、CAS机制优缺点
• 1>ABA问题
• 2>可能会消耗较高的CPU
• 3>不能保证代码块的原子性
• 二、Java提供的CAS操作类--Unsafe类
• 2.1、Unsafe类简介
• 2.2、Unsafe类的使用
• 三、CAS使用场景
• 3.1、使用一个变量统计网站的访问量
• 3.2、现在我们尝试在代码中引入AtomicInteger类
• 四、Java中的原子操作类
• 参考链接：
• 总结

前言： synchronized保证了线程安全，但是在某些情况下，却不是一个最优选择，关键在于性能问题。Java中提供了很多原子操作类来保证共享变量操作的原子性。这些原子操作的底层原理都是使用了CAS机制。既然用锁或 synchronized 关键字可以实现原子操作，那么为什么还要用 CAS 呢，因为加锁或使用 synchronized 关键字带来的性能损耗较大，而用 CAS 可以实现乐观锁，它实际上是直接利用了 CPU 层面的指令，没有加锁和线程上下文切换的开销，所以性能很高。

一、CAS机制简介

1.1、悲观锁和乐观锁更新数据方式

CAS机制是一种数据更新的方式。在具体讲什么是CAS机制之前，我们先来聊下在多线程环境下，对共享变量进行数据更新的两种模式：悲观锁模式和乐观锁模式。

悲观锁更新的方式认为：在更新数据的时候大概率会有其他线程去争夺共享资源，所以悲观锁的做法是：第一个获取资源的线程会将资源锁定起来，其他没争夺到资源的线程只能进入阻塞队列，等第一个获取资源的线程释放锁之后，这些线程才能有机会重新争夺资源。synchronized就是Java中悲观锁的典型实现，synchronized使用起来非常简单方便，但是会使没争抢到资源的线程进入阻塞状态，线程在阻塞状态和Runnable状态之间切换效率较低（比较慢）。比如你的更新操作其实是非常快的，这种情况下你还用synchronized将其他线程都锁住了，线程从Blocked状态切换回Runnable华的时间可能比你的更新操作的时间还要长。

乐观锁更新方式认为:在更新数据的时候其他线程争抢这个共享变量的概率非常小，所以更新数据的时候不会对共享数据加锁。但是在正式更新数据之前会检查数据是否被其他线程改变过，如果未被其他线程改变过就将共享变量更新成最新值，如果发现共享变量已经被其他线程更新过了，就重试，直到成功为止。CAS机制就是乐观锁的典型实现。

1.2、什么是CAS机制

CAS，是Compare and Swap的简称，是一种用于在多线程环境下实现同步功能的机制。CAS 操作包含三个操作数 -- 内存位置、预期数值和新值。CAS 的实现逻辑是将内存位置处的数值与预期数值相比较，若相等，则将内存位置处的值替换为新值。若不相等，则不做任何操作。

在 Java 中，Java 并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的。Java 代码需通过 JNI 才能调用。

CAS这个机制中有三个核心的参数：

主内存中存放的共享变量的值：V（一般情况下这个V是内存的地址值，通过这个地址可以获得内存中的值）

工作内存中共享变量的副本值，也叫预期值：A

需要将共享变量更新到的最新值：B

如上图中，主存中保存V值，线程中要使用V值要先从主存中读取V值到线程的工作内存A中，然后计算后变成B值，最后再把B值写回到内存V值中。多个线程共用V值都是如此操作。CAS的核心是在将B值写入到V之前要比较A值和V值是否相同，如果不相同证明此时V值已经被其他线程改变，重新将V值赋给A，并重新计算得到B，如果相同，则将B值赋给V。

值得注意的是CAS机制中的这步步骤是原子性的（从指令层面提供的原子操作），所以CAS机制可以解决多线程并发编程对共享变量读写的原子性问题。

1.3、CAS与sychronized比较

从思想上来说：

①. synchronized属于【悲观锁】

悲观锁认为：程序中的【并发】情况严重，所以【严防死守】

②. CAS属于【乐观锁】

乐观锁认为：程序中的【并发】情况不那么严重，所以让【线程不断去尝试更新】

这2种机制没有绝对的好与坏，关键看使用场景。在并发量非常高的情况下，反而用同步锁更合适一些。

1.4、Java中都有哪些地方应用到了CAS机制呢?

a、Atomic系列类

b、Lock系列类底层实现

c、Java1.6以上版本，synchronized转变为重量级锁之前，也会采用CAS机制

1.5、CAS 实现自旋锁

既然用锁或 synchronized 关键字可以实现原子操作，那么为什么还要用 CAS 呢，因为加锁或使用 synchronized 关键字带来的性能损耗较大，而用 CAS 可以实现乐观锁，它实际上是直接利用了 CPU 层面的指令，没有加锁和线程上下文切换的开销，所以性能很高。

上面也说了，CAS 是实现自旋锁的基础，CAS 利用 CPU 指令保证了操作的原子性，以达到锁的效果，至于自旋呢，看字面意思也很明白，自己旋转，翻译成人话就是循环，一般是用一个无限循环实现。这样一来，一个无限循环中，执行一个 CAS 操作，当操作成功，返回 true 时，循环结束；当返回 false 时，接着执行循环，继续尝试 CAS 操作，直到返回 true。

其实 JDK 中有好多地方用到了 CAS ,尤其是 java.util.concurrent包下，比如 CountDownLatch、Semaphore、ReentrantLock 中，再比如 java.util.concurrent.atomic 包下，相信大家都用到过 Atomic* ，比如 AtomicBoolean、AtomicInteger 等。

1.6、CAS机制优缺点

CAS虽然很高效的解决原子操作，但是CAS仍然存在三大问题。ABA问题，循环时间长开销大和只能保证一个共享变量的原子操作

CAS机制CAS机制缺点

1>ABA问题

ABA问题：CAS在操作的时候会检查变量的值是否被更改过，如果没有则更新值，但是带来一个问题，最开始的值是A，接着变成B，最后又变成了A。经过检查这个值确实没有修改过，因为最后的值还是A，但是实际上这个值确实已经被修改过了。为了解决这个问题，在每次进行操作的时候加上一个版本号，每次操作的就是两个值，一个版本号和某个值，A——>B——>A问题就变成了1A——>2B——>3A。在jdk中提供了AtomicStampedReference类解决ABA问题，用Pair这个内部类实现，包含两个属性，分别代表版本号和引用，在compareAndSet中先对当前引用进行检查，再对版本号标志进行检查，只有全部相等才更新值。

AtomicStampedReference和AtomicMarkableReference就是用来解决CAS中的ABA问题的。他们解决ABA问题的原理类似，都是通过一个版本号来区分有没被更新过。

AtomicStampedReference：带版本戳的原子引用类型，版本戳为int类型。

AtomicMarkableReference：带版本戳的原子引用类型，版本戳为boolean类型。

2>可能会消耗较高的CPU

看起来CAS比锁的效率高，从阻塞机制变成了非阻塞机制，减少了线程之间等待的时间。每个方法不能绝对的比另一个好，在线程之间竞争程度大的时候，如果使用CAS，每次都有很多的线程在竞争，也就是说CAS机制不能更新成功。这种情况下CAS机制会一直重试，这样就会比较耗费CPU。因此可以看出，如果线程之间竞争程度小，使用CAS是一个很好的选择；但是如果竞争很大，使用锁可能是个更好的选择。在并发量非常高的环境中，如果仍然想通过原子类来更新的话，可以使用AtomicLong的替代类：LongAdder。

3>不能保证代码块的原子性

Java中的CAS机制只能保证一个共享变量的原子操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

CAS机制优点

可以保证变量操作的原子性；

并发量不是很高的情况下，使用CAS机制比使用锁机制效率更高；

在线程对共享资源占用时间较短的情况下，使用CAS机制效率也会较高。

二、Java提供的CAS操作类--Unsafe类

2.1、Unsafe类简介

在研究JDK中AQS时，会发现这个类很多地方都使用了CAS操作，在并发实现中CAS操作必须具备原子性，而且是硬件级别的原子性，Java被隔离在硬件之上，明显力不从心，这时为了能直接操作操作系统层面，肯定要通过用C++编写的native本地方法来扩展实现。JDK提供了一个类来满足CAS的要求，sun.misc.Unsafe，从名字上可以大概知道它用于执行低级别、不安全的操作，AQS就是使用此类完成硬件级别的原子操作。UnSafe通过JNI调用本地C++代码，C++代码调用CPU硬件指令集。

Unsafe是一个很强大的类，它可以分配内存、释放内存、可以定位对象某字段的位置、可以修改对象的字段值、可以使线程挂起、使线程恢复、可进行硬件级别原子的CAS操作等等。

从Java5开始引入了对CAS机制的底层的支持，在这之前需要开发人员编写相关的代码才可以实现CAS。在原子变量类Atomic中（例如AtomicInteger、AtomicLong）可以看到CAS操作的代码，在这里的代码都是调用了底层（核心代码调用native修饰的方法）的实现方法。

在AtomicInteger源码中可以看getAndSet方法和compareAndSet方法之间的关系，compareAndSet方法调用了底层的实现，该方法可以实现与一个volatile变量的读取和写入相同的效果。在前面说到了volatile不支持例如i++这样的复合操作，在Atomic中提供了实现该操作的方法。JVM对CAS的支持通过这些原子类（Atomic***）暴露出来，供我们使用。

而Atomic系类的类底层调用的是Unsafe类的API，Unsafe类提供了一系列的compareAndSwap*方法，下面就简单介绍下Unsafe类的API：

long objectFieldOffset（Field field）方法：返回指定的变量在所属类中的内存偏移地址，该偏移地址仅仅在该Unsafe函数中访问指定字段时使用。如下代码使用Unsafe类获取变量value在AtomicLong对象中的内存偏移。

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

• int arrayBaseOffset（Class arrayClass）方法：获取数组中第一个元素的地址。
• int arrayIndexScale（Class arrayClass）方法：获取数组中一个元素占用的字节。
• boolean compareAndSwapLong（Object obj, long offset, long expect, long update）方法：比较对象obj中偏移量为offset的变量的值是否与expect相等，相等则使用update值更新，然后返回true，否则返回false，这次处理器提供的一个原子性指令。
• public native long getLongvolatile（Object obj, long offset）方法：获取对象obj中偏移量为offset的变量对应volatile语义的值。
• void putLongvolatile（Object obj, long offset, long value）方法：设置obj对象中offset偏移的类型为long的field的值为value，支持volatile语义。
• void putOrderedLong（Object obj, long offset, long value）方法：设置obj对象中offset偏移地址对应的long型field的值为value。这是一个有延迟的putLongvolatile方法，并且不保证值修改对其他线程立刻可见。只有在变量使用volatile修饰并且预计会被意外修改时才使用该方法。
• void park（boolean isAbsolute, long time）方法：阻塞当前线程，其中参数isAbsolute等于false且time等于0表示一直阻塞。time大于0表示等待指定的time后阻塞线程会被唤醒，这个time是个相对值，是个增量值，也就是相对当前时间累加time后当前线程就会被唤醒。如果isAbsolute等于true，并且time大于0，则表示阻塞的线程到指定的时间点后会被唤醒，这里time是个绝对时间，是将某个时间点换算为ms后的值。另外，当其他线程调用了当前阻塞线程的interrupt方法而中断了当前线程时，当前线程也会返回，而当其他线程调用了unPark方法并且把当前线程作为参数时当前线程也会返回。
• void unpark（Object thread）方法：唤醒调用park后阻塞的线程。

下面是JDK8新增的函数，这里只列出Long类型操作。

long getAndSetLong（Object obj, long offset, long update）方法：获取对象obj中偏移量为offset的变量volatile语义的当前值，并设置变量volatile语义的值为update。

//这个方法只是封装了compareAndSwapLong的使用，不需要自己写重试机制
public final long getAndSetLong(Object var1, long var2, long var4) {
    long var6;
    do {
        var6 = this.getLongVolatile(var1, var2);
    } while(!this.compareAndSwapLong(var1, var2, var6, var4));
    return var6;
}

long getAndAddLong（Object obj, long offset, long addValue）方法：获取对象obj中偏移量为offset的变量volatile语义的当前值，并设置变量值为原始值+addValue，原理和上面的方法类似。

2.2、Unsafe类的使用

三、CAS使用场景

• 使用一个变量统计网站的访问量；
• Atomic类操作；
• 数据库乐观锁更新。

3.1、使用一个变量统计网站的访问量

要实现一个网站访问量的计数器，可以通过一个Long类型的对象，并加上synchronized内置锁的方式。但是这种方式使得多线程的访问变成了串行的，同一时刻只能有一个线程可以更改long的值，那么为了能够使多线程并发的更新long的值，我们可以使用J.U.C包中的Atomic原子类。这些类的更新是原子的，不需要加锁即可实现并发的更新，并且是线程安全的。

可是Atomic原子类是怎么保证并发更新的线程安全的呢？让我们看一下AtomicLong的自增方法incrementAndGet()：

public final long incrementAndGet() {
    // 无限循环，即自旋
    for (;;) {
        // 获取主内存中的最新值
        long current = get();
        long next = current + 1;
        // 通过CAS原子更新，若能成功则返回，否则继续自旋
        if (compareAndSet(current, next))
            return next;
    }
}
private volatile long value;
public final long get() {
    return value;
}

可以发现其内部保持着一个volatile修饰的long变量，volatile保证了long的值更新后，其他线程能立即获得最新的值。
在incrementAndGet中首先是一个无限循环（自旋），然后获取long的最新值，将long加1，然后通过compareAndSet()方法尝试将long的值有current更新为next。如果能更新成功，则说明当前还没有其他线程更新该值，则返回next，如果更新失败，则说明有其他线程提前更新了该值，则当前线程继续自旋尝试更新。

简单总结

总体来说，AtomicBoolean、AtomicInteger、AtomicLong和AtomicReference原理比较简单：使用CAS保证原子性，使用volatile保证可见性，最终能保证共享变量操作的线程安全。

AtomicLongArray、AtomicIntArray和AtomicReferenceArray的实现原理略有不同，是用CAS机制配合final机制来实现共享变量操作的线程安全的。感兴趣的同学可以自己分析下，也是比较简单的。

CAS的操作其底层是通过调用sun.misc.Unsafe类中的CompareAndSwap的方法保证线程安全的。Unsafe类中主要有下面三种CompareAndSwap方法：

public final native boolean compareAndSwapObject(Object obj, long offset, Object expect, Object update);
public final native boolean compareAndSwapInt(Object obj, long offset, int expect, int update);
public final native boolean compareAndSwapLong(Object obj, long offset, long expect, long update);

可以看到这些方法都是native的，需要调用JNI接口，也即通过操作系统来保证这些方法的执行。

3.2、现在我们尝试在代码中引入AtomicInteger类

在使用Integer的时候，必须加上synchronized保证不会出现并发线程同时访问的情况

public class AtomicInteger {
    private static Integer count =0;
    public static void main(String[] args) {
        //开启两个线程
        for(int i=0;i<2;i++)
        {
            new Thread(new Runnable()
            {
                @Override
                public void run()
                {
                    //每个线程当中让count自增1000次
                    for(int j=0;j<1000;j++)
                    {
                        increment();
                    }
                }
            }).start();
        }
        //让主线程睡2秒，避免直接打印count值为0
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("count="+count);
    }
    //加上synchronized保证不会出现并发线程同时访问的情况,否则结果可能只有1千多
     public synchronized static void increment() {
        count++;
    }
}

而在AtomicInteger中却不用加上synchronized，在这里AtomicInteger是提供原子操作的

在某些情况下，原子类代码的性能会比Synchronized更好，因为没有加锁的线程同步上下文切换开销，底层采用了CAS机制保证共享变量原子性，还配合volatile保证内存可见性，最终能保证共享变量操作的线程安全。

四、Java中的原子操作类

在JDK1.5版本之前，多行代码的原子性主要通过synchronized关键字进行保证。在JDK1.5版本，Java提供了原子类型专门确保变量操作的原子性。所谓的原子操作类，指的是java.util.concurrent.atomic包下，一系列以Atomic开头的包装类。例如：AtomicBoolean，AtomicInteger，AtomicLong。它们分别用于Boolean，Integer，Long类型的原子性操作。

为了方面对这些类逐级掌握，我将这些原子类型分为以下几类：

• 普通原子类型：提供对boolean、int、long和对象的原子性操作。
  • AtomicBoolean
  • AtomicInteger
  • AtomicLong
  • AtomicReference
• 原子类型数组：提供对数组元素的原子性操作。
  • AtomicLongArray
  • AtomicIntegerArray
  • AtomicReferenceArray
• 原子类型字段更新器：提供对指定对象的指定字段进行原子性操作。
  • AtomicLongFieldUpdater
  • AtomicIntegerFieldUpdater
  • AtomicReferenceFieldUpdater
• 带版本号的原子引用类型：以版本戳的方式解决原子类型的ABA问题。
  • AtomicStampedReference
  • AtomicMarkableReference
• 原子累加器(JDK1.8)：AtomicLong和AtomicDouble的升级类型，专门用于数据统计，性能更高。
  • DoubleAccumulator
  • DoubleAdder
  • LongAccumulator
  • LongAdder

原子类型累加器是JDK1.8引进的并发新技术，它可以看做AtomicLong和AtomicDouble的部分加强类型。低并发、一般的业务场景下AtomicLong是足够了。如果并发量很多，存在大量写多读少的情况，那LongAdder可能更合适，代价是消耗更多的内存空间。

AtomicLong中有个内部变量value保存着实际的long值，所有的操作都是针对该变量进行。也就是说，高并发环境下，value变量其实是一个热点，也就是N个线程竞争一个热点。在并发量较低的环境下，线程冲突的概率比较小，自旋的次数不会很多。但是，高并发环境下，N个线程同时进行自旋操作，会出现大量失败并不断自旋的情况，此时AtomicLong的自旋会成为瓶颈。

这就是LongAdder引入的初衷——解决高并发环境下AtomicLong的自旋瓶颈问题。

LongAdder的基本思路就是分散热点，将value值分散到一个数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行CAS操作，这样热点就被分散了，冲突的概率就小很多。如果要获取真正的long值，只要将各个槽中的变量值累加返回。这种做法有没有似曾相识的感觉？没错，
ConcurrentHashMap中的“分段锁”其实就是类似的思路。

参考链接：

并发编程的基石——CAS机制

深入理解CAS机制

Atomic系列类整体介绍

原子类型累加载器

总结

本篇文章就到这里了，希望能够给你带来帮助，也希望您能够多多关注自由互联的更多内容！

【文章转自：http://www.1234xp.com/xjp.html 复制请保留原URL】