java高并发：CAS无锁原理及广泛应用

欢迎关注本人公众号

前言

在现在的互联网技术领域，用户流量越来越大，系统中并发量越来越大，大公司的日活动辄成百上千万。如何面对如此高的并发是当今互联网技术圈一直在努力的事情。
应对高并发需要在各个技术层面进行合理的设计和技术选型才可以。本文只讲述微观层面是如何应对多线程高并发的，介绍著名的CAS原理以及其广泛应用。

本文中jdk版本使用的是jdk1.7.0_55. 不同版本实现可能稍有差异.

CAS无锁实现原理

为什么要用CAS

在多线程高并发编程的时候，最关键的问题就是保证临界区的对象的安全访问。通常是用加锁来处理，其实加锁本质上是将并发转变为串行来实现的，势必会影响吞吐量。而且线程的数量是有限的，依赖于操作系统，而且线程的创建和销毁带来的性能损耗是不可以忽略掉的。虽然现在基本都是用线程池来尽可能的降低不断创建线程带来的性能损耗。

对于并发控制而言，锁是一种悲观策略，会阻塞线程执行。而无锁是一种乐观策略，它会假设对资源的访问时没有冲突的，既然没有冲突就不需要等待，线程不需要阻塞。那多个线程共同访问临界区的资源怎么办呢，无锁的策略采用一种比较交换技术**CAS（compare and swap）**来鉴别线程冲突，一旦检测到冲突，就充实当前操作指导没有冲突为止。

与锁相比，CAS会使得程序设计比较负责，但是由于其优越的性能优势，以及天生免疫死锁（根本就没有锁，当然就不会有线程一直阻塞了），更为重要的是，使用无锁的方式没有所竞争带来的开销，也没有线程间频繁调度带来的开销，他比基于锁的方式有更优越的性能，所以在目前被广泛应用，我们在程序设计时也可以适当的使用.

不过由于CAS编码确实稍微复杂，而且jdk作者本身也不希望你直接使用unsafe（后面会讲到）来进行代码的编写，所以如果不能深刻理解CAS以及unsafe还是要慎用，使用一些别人已经实现好的无锁类或者框架就好了。

CAS原理分析

CAS算法

一个CAS方法包含三个参数CAS(V,E,N)。V表示要更新的变量，E表示预期的值，N表示新值。只有当V的值等于E时，才会将V的值修改为N。如果V的值不等于E，说明已经被其他线程修改了，当前线程可以放弃此操作，也可以再次尝试次操作直至修改成功。基于这样的算法，CAS操作即使没有锁，也可以发现其他线程对当前线程的干扰（临界区值的修改），并进行恰当的处理。

• 额外引申技术点：volatile

上面说到当前线程可以发现其他线程对临界区数据的修改，这点可以使用volatile进行保证。
volatile实现了JMM中的可见性。使得对临界区资源的修改可以马上被其他线程看到，它是通过添加内存屏障实现的。具体实现原理请自行搜索**volatile**

AtomicInteger

初次接触CAS的人一般都是通过AtomicInteger这个类来了解的，这里讲其原理也借助这个类。

查看一下AtomicInteger的源码：

private volatile int value;

//此处省略一万字代码

/**
 * Atomically sets to the given value and returns the old value.
 *
 * @param newValue the new value
 * @return the previous value
 */
public final int getAndSet(int newValue) {
    for (;;) {
        int current = get();
        if (compareAndSet(current, newValue))
            return current;
    }
}


/**
 * Atomically sets the value to the given updated value
 * if the current value {@code ==} the expected value.
 *
 * @param expect the expected value
 * @param update the new value
 * @return true if successful. False return indicates that
 * the actual value was not equal to the expected value.
 */
public final boolean compareAndSet(int expect, int update) {
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

通过这段代码可知：

• AtomicInteger中真正存储数据的是value变量，而改变量是被volatile修饰的，保证了线程直接的可见性。还记得Integer中的value吗？Integer中的value是被final修饰的，是不可变对象。
• getAndSet方法通过一个死循环不断尝试赋值操作。而真正的赋值操作交给了unsafe类来实现。

unsafe

上面可知，Unsafe类是CAS实现的核心。
从名字可知，这个类标记为不安全的，JDK作者不希望用户使用这个类，我们看一下他的构造方法：

public static Unsafe getUnsafe() {
    Class var0 = Reflection.getCallerClass();
    if(var0.getClassLoader() != null) {
        throw new SecurityException("Unsafe");
    } else {
        return theUnsafe;
    }
}

如果ClassLoader不是null,直接抛出异常了，我们没办法在应用程序中使用这个类

public static void main(String[] args){
    Unsafe unsafe = Unsafe.getUnsafe();
}

main方法运行结果：

Exception in thread "main" java.lang.SecurityException: Unsafe
    at sun.misc.Unsafe.getUnsafe(Unsafe.java:90)
    at com.le.luffi.Tewast.main(Tewast.java:13)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

我们来看一下compareAndSwapInt的方法声明

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

第一个参数是给定的对象，offset是对象内的偏移量（其实就是一个字段到对象头部的偏移量，通过这个偏移量可以快速定位字段），第三个参数是期望值，最后一个是要设置的值。

其实这里Unsafe封装了一些类似于C++中指针的东西，该类中的方法都是native的，而且是原子的操作。原子性是通过CAS原子指令实现的，由处理器保证。

讲到这里相信读者肯定明白CAS是个什么鬼了。

CAS的问题

• CAS容易造成ABA问题。ABA：一个线程将某一内存地址中的数值A改成了B，接着又改成了A，此时CAS认为是没有变化，其实是已经变化过了，而这个问题的解决方案可以使用版本号标识，每操作一次version加1。在java5中，已经提供了AtomicStampedReference来解决问题。
  CAS操作容易导致ABA问题,也就是在做i++之间，i可能被多个线程修改过了，只不过回到了最初的值，这时CAS会认为i的值没有变。i在外面逛了一圈回来，你能保证它没有做任何坏事，不能！！也许它把b的值减了一下，把c的值加了一下等等，更有甚者如果i是一个对象，这个对象有可能是新创建出来的，i是一个引用情况又如何，所以这里面还是存在着很多问题的，解决ABA问题的方法有很多，可以考虑增加一个修改计数，只有修改计数不变的且i值不变的情况下才做i++，也可以考虑引入版本号，当版本号相同时才做i++操作等，这和事务原子性处理有点类似。

• CAS造成CPU利用率增加。之前说过了CAS里面是一个循环判断的过程，如果线程一直没有获取到状态，cpu资源会一直被占用。

• 会增加程序测试的复杂度，稍不注意就会出现问题。

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

ABA的解决办法

如果一开始位置V得到的旧值是A，当进行赋值操作时再次读取发现仍然是A，并不能说明变量没有被其它线程改变过。有可能是其它线程将变量改为了B，后来又改回了A。大部分情况下ABA问题不会影响程序并发的正确性，如果要解决ABA问题，用传统的互斥同步可能比原子类更高效。可以用CAS在无锁的情况下实现原子操作，但要明确应用场合，非常简单的操作且又不想引入锁可以考虑使用CAS操作，当想要非阻塞地完成某一操作也可以考虑CAS。不推荐在复杂操作中引入CAS，会使程序可读性变差，且难以测试，同时会出现ABA问题。

ABA问题的解决办法：

1. 在变量前面追加版本号：每次变量更新就把版本号加1，则A-B-A就变成1A-2B-3A。
2. atomic包下的AtomicStampedReference类：其compareAndSet方法首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用的该标志的值设置为给定的更新值。

在java领域的广泛应用

jdk中的CAS实现

java.util.concurrent.atomic包

该包下的类都是采用CAS来实现的无锁，读者可以亲自去尝试使用。

跳跃表java.util.concurrent.ConcurrentSkipListMap

ConcurrentSkipListMap采用典型的空间换取时间策略，它是一个有序的，支持高并发的Map.

实现原理参见 Java多线程（四）之ConcurrentSkipListMap深入分析
他对节点的操作都是CAS机制实现的

无锁队列java.util.concurrent.ConcurrentLinkedQueue

实现原理参见 聊聊并发（六）ConcurrentLinkedQueue的实现原理分析

并发编程网是个不错的网站

JVM中的CAS

堆中对象的分配

我们都知道java调用new object()会创建一个对象，这个对象会被分配到JVM的堆中。那么这个对象到底是怎么在堆中保存的呢？

首先，new object()执行的时候，这个对象需要多大的空间，其实是已经确定的，因为java中的各种数据类型，占用多大的空间都是固定的（对其原理不清楚的请自行Google）。那么接下来的工作就是在堆中找出那么一块空间用于存放这个对象。
在单线程的情况下，一般有两种分配策略：

1. 指针碰撞
   这种一般适用于内存是绝对规整的（内存是否规整取决于内存回收策略），分配空间的工作只是将指针像空闲内存一侧移动对象大小的距离即可。
2. 空闲列表
   这种适用于内存非规整的情况，这种情况下JVM会维护一个内存列表，记录那些内存区域是空闲的，大小是多少哦啊。给对象分配空间的时候去空闲列表里查询到合适的区域然后进行分配即可

但是JVM不可能一直在单线程状态下运行，那样效率太差了。由于再给一个对象分配内存的时候不是原子性的操作，至少需要以下几步：查找空闲列表、分配内存、修改空闲列表等等，这是不安全的。解决并发时的安全问题也有两种策略：

1. CAS
   实际上虚拟机采用CAS配合上失败重试的方式保证更新操作的原子性，原理和上面讲的一样。
2. TLAB
   如果使用CAS其实对性能还是会有影响的，所以JVM又提出了一种更高级的优化策略：每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲区（TLAB），线程内部需要分配内存时直接在TLAB上分配就行，避免了线程冲突。只有当缓冲区的内存用光需要重新分配内存的时候才会进行CAS操作分配更大的内存空间。
   虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来进行配置（jdk5及以后的版本默认是启用TLAB的）。

高性能内存队列disruptor中的CAS

实现原理参考并发编程网 并发框架Disruptor译文

数据库乐观锁机制

数据中的锁分为两类：悲观锁和乐观锁，锁还有表级锁、行级锁
表级锁例如：
SELECT * FROM table WITH (HOLDLOCK) 其他事务可以读取表，但不能更新删除
SELECT * FROM table WITH (TABLOCKX) 其他事务不能读取表, 更新和删除
行级锁例如：
select * from table_name where id = 1 for update;

悲观锁（Pressimistic Locking）

对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。例如：
select * from table_name where id = ‘xxx’ for update;
这样查询出来的这一行数据就被锁定了,在这个update事务提交之前其他外界是不能修改这条数据的，但是这种处理方式效率比较低，一般不推荐使用。

乐观锁（Optimistic Locking）

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

乐观锁的实现：

Update Account set field1=? and field2=? and  version = version+1 where version = ?...(another contidition)