CAS和AQS

喜欢ヅ旅行 2023-10-02 22:11 2阅读 0赞

#### 文章目录 ####

*  一、什么是 CAS（比较并交换-乐观锁机制-锁自旋）？
 *   *  1.概念及特性
     *  2.原子包 java.util.concurrent.atomic（锁自旋）
     *  3.ABA问题
 *  二、什么是 AQS（抽象的队列同步器）
 *  总结

--------------------

## 一、什么是 CAS（比较并交换-乐观锁机制-锁自旋）？ ##

### 1.概念及特性 ###

CAS（Compare And Swap/Set）比较并交换，CAS 算法的过程是这样：它包含 3 个参数CAS(V,E,N)。V **表示要更新的变量(内存值)，E 表示预期值(旧的)，N 表示新值。当且仅当 V 值等于 E 值时，才会将 V 的值设为 N，如果 V 值和 E 值不同，则说明已经有其他线程做了更新，则当前线程什么都不做**。最后，CAS 返回当前 V 的真实值。CAS 操作是抱着乐观的态度进行的(乐观锁)，它总是认为自己可以成功完成操作。**当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作**。基于这样的原理，  
CAS 操作即使没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。

### 2.原子包 java.util.concurrent.atomic（锁自旋） ###

JDK1.5 的原子包：java.util.concurrent.atomic 这个包里面提供了一组原子类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由 JVM 从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。  
相对于对于 synchronized 这种阻塞算法，CAS 是非阻塞算法的一种常见实现。由于一般 CPU 切换时间比 CPU 指令集操作更加长， 所以 J.U.C 在性能上有了很大的提升。如下代码：

public class AtomicInteger extends Number implements java.io.Serializable {
         
     private volatile int value; 
    public final int get() {
         
     return value; 
     } 
     public final int getAndIncrement() {
         
     for (;;) {
         //CAS 自旋，一直尝试，直达成功
     int current = get(); 
     int next = current + 1; 
     if (compareAndSet(current, next)) 
     return current; 
     } 
     } 
     public final boolean compareAndSet(int expect, int update) {
         
     return unsafe.compareAndSwapInt(this, valueOffset, expect, update); 
     } 
    }

### 3.ABA问题 ###

CAS 会导致“ABA 问题”。CAS 算法实现一个重要前提需要取出内存中某时刻的数据，而在下时刻比较并替换，那么在这个时间差类会导致数据的变化。**比如说一个线程 one 从内存位置 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且two 进行了一些操作变成了 B，然后 two 又将 V 位置的数据变成 A，这时候线程 one 进行 CAS 操作发现内存中仍然是 A，然后 one 操作成功。尽管线程 one 的 CAS 操作成功，但是不代表这个过程就是没有问题的。**  
部分乐观锁的实现是通过版本号（version）的方式来解决 ABA 问题，乐观锁每次在执行数据的修  
改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本  
号执行+1 操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现 ABA 问  
题，因为版本号只会增加不会减少。

## 二、什么是 AQS（抽象的队列同步器） ##

AbstractQueuedSynchronizer 类如其名，抽象的队列式的同步器，**AQS 定义了一套多线程访问共享资源的同步器框架**，许多同步类实现都依赖于它，如常用的**ReentrantLock/Semaphore/CountDownLatch**。  
![在这里插入图片描述][78bd55646a7d48aeb1ea3c2c39674423.png]  
它维护了一个 volatile int state（代表共享资源）和一个 FIFO 线程等待队列（多线程争用资源被  
阻塞时会进入此队列）。这里 volatile 是核心关键词，具体 volatile 的语义，在此不述。state 的  
访问方式有三种:  
getState()  
setState()  
compareAndSetState()  
***AQS 定义两种资源共享方式***  
**Exclusive 独占资源-ReentrantLock**  
Exclusive（独占，只有一个线程能执行，如 ReentrantLock）  
**Share 共享资源-Semaphore/CountDownLatch**  
Share（共享，多个线程可同时执行，如 Semaphore/CountDownLatch）。AQS 只是一个框架，具体资源的获取/释放方式交由自定义同步器去实现，AQS 这里只定义了一个接口，具体资源的获取交由自定义同步器去实现了（通过 state 的 get/set/CAS)之所以没有定义成abstract ，是 因 为独 占模 式 下 只 用实现 tryAcquire-tryRelease ，而 共享 模 式 下 只用 实 tryAcquireShared-tryReleaseShared。如果都定义成abstract，那么每个模式也要去实现另一模式下的接口。不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS 已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：  
1．isHeldExclusively()：该线程是否正在独占资源。只有用到 condition 才需要去实现它。  
2．tryAcquire(int)：独占方式。尝试获取资源，成功则返回 true，失败则返回 false。  
3．tryRelease(int)：独占方式。尝试释放资源，成功则返回 true，失败则返回 false。  
4．tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0 表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。  
5．tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回 false。  
**同步器的实现是 AQS 核心（state 资源状态计数）**  
同步器的实现是 AQS 核心，以 ReentrantLock 为例，state 初始化为 0，表示未锁定状态。A 线程lock()时，会调用 tryAcquire()独占该锁并将 state+1。此后，其他线程再 tryAcquire()时就会失败，直到 A 线程 unlock()到 state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证 state 是能回到零态的。以 CountDownLatch 以例，任务分为 N 个子线程去执行，state 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown()一次，state  
会 CAS 减 1。等到所有子线程都执行完后(即 state=0)，会 unpark()主调用线程，然后主调用线程就会从 await()函数返回，继续后余动作。  
**ReentrantReadWriteLock 实现独占和共享两种方式**  
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现 tryAcquiretryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 **AQS 也支持自定义同步器同时实现独占和共享两种方式，如 ReentrantReadWriteLock**。

--------------------

## 总结 ##

以上为个人学习过程中对java的一些学习总结，如有错误，欢迎各位批评指导，如有侵权，请联系本人删除，谢谢！

[78bd55646a7d48aeb1ea3c2c39674423.png]: https://img-blog.csdnimg.cn/78bd55646a7d48aeb1ea3c2c39674423.png