首页手记【多线程系列】CAS、AQS简单介绍

【多线程系列】CAS、AQS简单介绍

标签：

Java

什么是CAS

CAS(Compare And Swap)，即比较并交换。是解决多线程并行情况下使用锁造成性能损耗的一种机制，CAS操作包含三个操作数——内存位置(V)、预期原值(A)和新值(B)。如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在CAS指令之前返回该位置的值。CAS有效地说明了“我认为位置V应该包含值A；如果包含该值，则将B放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。
在JAVA中，sun.misc.Unsafe 类提供了硬件级别的原子操作来实现这个CAS。 java.util.concurrent 包下的大量类都使用了这个 Unsafe.java 类的CAS操作。

CAS典型应用

java.util.concurrent.atomic 包下的类大多是使用CAS操作来实现的，比如 AtomicInteger、AtomicBoolean、AtomicLong。一般来说在竞争不是特别激烈的时候，使用该包下的原子操作性能比使用 synchronized 关键字的方式高效的多(查看getAndSet()，可知如果资源竞争十分激烈的话，这个for循环可能会持续很久都不能成功跳出。不过这种情况可能需要考虑降低资源竞争才是)。
在较多的场景我们都可能会使用到这些原子类操作。一个典型应用就是计数了，在多线程的情况下需要考虑线程安全问题。
一、现在有这么一个需求，需要实现一个支持并发的计数功能，例如下面的代码

在并发环境下对 count 进行自增运算是不安全的，为什么不安全以及如何解决这个问题呢？

二、为什么并发环境下的count自增操作不安全

因为count++不是原子操作，而是三个原子操作的组合：

读取内存中的count值赋值给局部变量temp
执行temp+1操作
将temp赋值给count

所以如果两个线程同时执行 count++ 操作的话，我们不能保证线程一按顺序执行完上述三步后线程二才开始执行。

三、并发环境下count++不安全问题的解决方案
方案一：synchronized 加锁

加锁后代码如上，同一时间只有一个线程能加锁，其他线程需要等待锁，这样就不会出现count 计数不准确的问题了，现在线程安全。。

但是引入synchronized会造成多个线程排队的问题，同一时间只有一个线程执行，这样的锁有点儿“重量级”了。这类似于悲观锁的实现，我需要获取这个资源，那么我就给它加锁，别的线程都无法访问该资源，直到我操作完后释放对该资源的锁。虽然随着Java版本更新，也对synchronized做了很多优化，但是处理这种简单的累加操作，仍然显得“太重了”。人家synchronized是可以解决更加复杂的并发编程场景和问题的。

而且在这个场景下，若用synchronized，不就相当于让各个线程串行化了么？一个接一个的排队、加锁、处理数据、释放锁，下一个再进来。

方案二：Atomic 原子类

对于这种的count++类的操作，我们完全可以换一种做法，java并发包下面提供了一系列的Atomic原子类，比如说AtomicInteger

多个线程可以并发的执行 AtomicInteger 的 incrementAndGet() 方法，意思就是给我把count的值累加1，接着返回累加后最新的值。实际上，Atomic原子类底层用的不是传统意义的锁机制，而是无锁化的CAS机制，通过CAS机制保证多线程修改一个数值的安全性。

四、CAS底层实现原理是什么
流程图如下：

假如说有3个线程并发的要修改一个AtomicInteger的值，他们底层的机制如下：

首先，每个线程都会先获取当前的值。接着走一个原子的CAS操作，原子的意思就是这个CAS操作一定是自己完整执行完的，不会被别人打断。
然后CAS操作里，会比较一下，现在你的值是不是刚才我获取到的那个值。如果是，说明没人改过这个值，那你给我设置成累加1之后的一个值。
同理，如果有人在执行CAS的时候，发现自己之前获取的值跟当前的值不一样，会导致CAS失败，失败之后，进入一个无限循环，再次获取值，接着执行CAS操作。

CAS有没有什么问题？

五、CAS性能优化
从上面的流程图其实可以看出来，比如说大量的线程同时并发修改一个 AtomicInteger，可能有很多线程会不停的自旋，进入一个无限重复的循环中。
这些线程不停地获取值，然后发起CAS操作，但是发现这个值被别人改过了，于是再次进入下一个循环，获取值，发起CAS操作又失败了，再次进入下一个循环。
在大量线程高并发更新 AtomicInteger 的时候，这种问题可能会比较明显，导致大量线程空循环，自旋转，性能和效率都不是特别好。那么如何优化呢？

Java 8有一个新的类，LongAdder，他就是尝试使用分段CAS以及自动分段迁移的方式来大幅度提升多线程高并发执行CAS操作的性能，这个类具体是如何优化性能的呢？如图：

LongAdder核心思想就是热点分离，这一点和ConcurrentHashMap的设计思想相似。就是将value值分离成一个数组，当多线程访问时，通过hash算法映射到其中的一个数字进行计数。而最终的结果，就是这些数组的求和累加。这样一来，就减小了锁的粒度。

LongAddr的兄弟类如下：

什么是AQS

AQS(AbstractQueuedSynchronizer)，AQS是JDK下提供的一套用于实现基于FIFO等待队列的阻塞锁和相关的同步器的一个同步框架。它使用了一个原子的int value status来作为同步器的状态（如：独占锁，1代表已占有，0代表未占有），通过该类提供的原子修改status方法（getState setState and compareAnsSetState），我们可以把它作为同步器的基础框架类来实现各种同步器。AQS还定义了一个实现了Condition接口的ConditionObject内部类。Condition 将 Object 监视器方法（wait、notify 和 notifyAll）分解成截然不同的对象，以便通过将这些对象与任意 Lock 实现组合使用，为每个对象提供多个等待 set （wait-set）。其中，Lock 替代了 synchronized 方法和语句的使用，Condition 替代了 Object 监视器方法的使用。
简单来说，就是Condition提供类似于Object的wait、notify的功能signal和await，都是可以使一个正在执行的线程挂起（推迟执行），直到被其他线程唤醒。但是Condition更加强大，如支持多个条件谓词、保证线程唤醒的顺序和在挂起时不需要拥有锁。这个抽象类被设计为作为一些可用原子int值来表示状态的同步器的基类。如果你有看过类似 CountDownLatch 类的源码实现，会发现其内部有一个继承了 AbstractQueuedSynchronizer 的内部类 Sync。可见 CountDownLatch 是基于AQS框架来实现的一个同步器.类似的同步器在JUC下还有不少。(eg. Semaphore)