AQS 和CAS详解

最新推荐文章于 2024-04-27 17:30:34 发布

林在闪闪发光

最新推荐文章于 2024-04-27 17:30:34 发布

阅读量2.3k

点赞数 12

文章标签： java 数据库开发语言

本文链接：https://blog.csdn.net/weixin_68829137/article/details/130248143

版权

🏆今日学习目标：

🍀JDBC事务 Hibernate事务 EJB事务详解
✅创作者：林在闪闪发光
⏰预计时间：30分钟
🎉个人主页：林在闪闪发光的个人主页

🍁林在闪闪发光的个人社区，欢迎你的加入: 林在闪闪发光的社区

无论如何，你一定要去试一试，就算你不能证明你可以，那也要证明你不可以。

什么是AQS

AQS ( Abstract Queued Synchronizer ）是一个抽象的队列同步器，通过维护一个共享资源状态（ Volatile Int State ）和一个先进先出（ FIFO ）的线程等待队列来实现一个多线程访问共享资源的同步框架。

一、AQS原理

AQS 为每个共享资源都设置一个共享资源锁，线程在需要访问共享资源时首先需要获取共享资源锁，如果获取到了共享资源锁，便可以在当前线程中使用该共享资源，如果获取不到，则将该线程放入线程等待队列，等待下一次资源调度，具体的流程如图所示。许多同步类的实现都依赖于AQS ，例如常用的 ReentrantLock、Semaphore、CountDownLatch。

二、state：状态

Abstract Queued Synchronizer 维护了 volatile int 类型的变量，用于表示当前的同步状态。volatile虽然不能保证操作的原子性，但是能保证当前变量state的可见性。
state的访问方式有三种： getState()、setState()和 compareAndSetState()，均是原子操作，其中，compareAndSetState的实现依赖于 Unsafe的compareAndSwaplnt() 具体的。JDK 码实现如下：

三、AQS共享资源的方式：独占式和共享式

AQS 定义了两种资源共享方式：独占式 (Exclusive)和共享式(Share)

独占式:只有一个线程能执行，具体的 Java 实现有 ReentrantLock。
共享式：多个线程可同时执行，具体的 Java 实现有 Semaphore和CountDownLatch。

AQS只是一个框架，只定义了一个接口，具体资源的获取、释放都由自定义同步器去实现。不同的自定义同步器争用共享资源的方式也不同，自定义同步器在实现时只需实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护，如获取资源失败入队、唤醒出队等， AQS 已经在顶层实现好，不需要具体的同步器再做处理。自定义同步器的主要方法如图所示:

同步器的实现是 AQS的核心内存。 ReentrantLock对AQS的独占方式实现为：ReentrantLock中的state初始值为0表示无锁状态。在线程执行 tryAcquire()获取该锁后ReentrantLock中的state+1，这时该线程独占ReentrantLock锁，其他线程在通过tryAcquire() 获取锁时均会失败，直到该线程释放锁后state再次为0，其他线程才有机会获取该锁。该线程在释放锁之前可以重复获取此锁，每获取一次便会执行一次state+1, 因此ReentrantLock也属于可重入锁。但获取多少次锁就要释放多少次锁，这样才能保证state最终为0。如果获取锁的次数多于释放锁的次数，则会出现该线程一直持有该锁的情况；如果获取锁的次数少于释放锁的次数，则运行中的程序会报锁异常。
CountDownLatch对AQS的共享方式实现为：CountDownLatch 将任务分为N个子线程去执行，将 state 初始化为 N, N与线程的个数一致，N个子线程是井行执行的，每个子线程都在执行完成后 countDown()1次， state 执行 CAS 操作并减1。在所有子线程都执行完成( state=O)时会unpark()主线程，然后主线程会从 await()返回，继续执行后续的动作。

一般来说，自定义同步器要么采用独占方式，要么采用共享方式，实现类只需实现tryAcquire、tryseAcquireShared、tryReleaseShared 中的一组即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，例如 ReentrantReadWriteLock 在读取时采用了共享方式，在写入时采用了独占方式。

CAS是什么

比较并交换，在多线程环境下尽量不要用i++,要用getAndIncrement()

首先想一个场景当多线程操作同一个数据时，不同的线程都要从中拿到这个数据的副本，然后进行修改之后放回去。

看下面一个例子：

public class CASDemo {
    public static void main(String[] args) {
        AtomicInteger atomicInteger = new AtomicInteger(5);

        System.out.println(atomicInteger.compareAndSet(5, 2019) + "\t current data: " + atomicInteger.get());
        System.out.println(atomicInteger.compareAndSet(5, 1024) + "\t current data: " + atomicInteger.get());
    }
}

看下结果

用图来解释一下这个结果

两个工作线程(其实都是main线程的，演示方便就当两个看吧)都想修改主物理内存的值，调用compareAndSet()函数首先工作线程1拿到主物理内存的5然后拷贝一个副本放在自己这然后把这个副本与期望值相比发现相等所以返回true并将5改成2019写会主物理内存并通知其他线程可见，工作线程2再去拿到主物理内存的值2019作为拷贝副本将这个副本与实际的期望值相比不是5所以返回false主物理内存的值也无法得到有效更改。

1. CAS底层原理

首先我们先来探讨一下为什么atomicInteger.getAndIncrement();能够保证线程安全先看一下他的源码

它会调用unsafe类的getAndAddInt方法CAS能保证原子性靠的就是底层的unsafe类这个东西是打娘胎里带的在D:\jdk\jre\lib\rt.jar里面在sun.misc这个包下。CAS是JAVA的核心类，JAVA不能直接和操作系统打交道，需要靠本地方法的帮助，其中的方法可以向C的指针一样直接操作内存。unsafe类的几乎所有方法都是native修饰的，直接调用底层资源执行相应任务。这个方法会拿到当前对象和当前对象的地址，然后加一。

CAS全称是Compare-And-Swap，它是一条CPU并发原语，它的功能是判断内存某个位置是否为预期值如果是则更改为新的值，这个过程是原子的。原语是操作系统的语言是由若干条指令组成的，用于完成某一个功能的过程，原语执行必须是连续的不能被打断也就是说CAS操作是原子的所以atomicInteger.getAndIncrement()能保证线程安全。那为什么CAS原子操作就能保证不被中断呢这涉及到了底层的一些东西Unsafe类中的compareAndSwapInt，是一个本地方法该方法位于unsafe.cpp中其中的Atomic::cmpxchg(x,addr,e)只要有Atomic那他就不可被中断一定是原子的x是新值和addr上之前的值e作比较如果相等则替换不然就不换。

看一下unsafe类的getAndAddInt方法：

    public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

这里头var1就是当前对象，var2就是当前对象的内存地址，var4就是要加的数，getIntvolatile就是获得当前var2地址中的值，可以理解为从当前主物理内存中拷贝一份到自己的本地内存var5，然后循环执行compareAndSwapInt比较在当前var2地址上var1和var5的值是否相等如果不相等说明主物理内存已经被其他工作线程改过返回false不断循环，如果var1和var5的值相等返回true说明主物理内存的值没被改过，将其修改为var5+var4然后写回主物理内存。

2. CAS缺点

1.首先我们可以看到getAndAddInt方法执行时，有个do while如果CAS失败他就会一直尝试。如果CAS长时间一直不成功，可能会给CPU带来很大的开销。

2.CAS只能保证一个共享变量的原子性，对多个共享变量的原子性往往无能为力，这时候就必须用锁来保证它的原子性。

3.他会引发ABA问题

3. ABA问题

黑色线段为一开始主物理内存的值是A，黄色代表线程1，线程一2s能完成，线程二10s才能完成，一开始主物理内存的值为A，线程一，线程二获得主物理内存的值，这时候由于线程一花费2s时间将主物理内存值从A改成B，然后再画2s将主物理内存从B变成A，又花了2s时间将主物理内存从A改成B，又花费2s将主物理内存改成A，再过2s主物理内存的值仍为A，此时线程二进入将当前主物理内存的值和当初拿到的主物理内存作比较发现相等这时候就对主物理内存中的只进行修改改成B。看似线程2在进行CAS操作的过程中一切顺利但是中间主物理内存的值被改了很多遍，如果你不在意他的过去，只看当下(即开头结尾一致)那就没问题，如果你在意他的过去那这就是有问题的。

3.1原子引用

上面一直在说的AtomicInteger类是专门操作Integer型的数据，如果你想操作其他类型并且要求其他类型也是原子的那就可以使用。

class User{
    String name;
    int age;

    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    @Override
    public String toString() {
        return name + "," +  age;
    }
}
public class AtomicReferenceDemo {
    public static void main(String[] args) {
        User bigwjz = new User("大温",22);
        User smallwjz = new User("小温",2);
        AtomicReference<User> atomicReference = new AtomicReference<>();
        atomicReference.set(bigwjz);//通过这行代码将一开始主物理内存的值设置为bigwjz
        System.out.println(atomicReference.compareAndSet(bigwjz, smallwjz) + "\t" + atomicReference.get().toString());
        System.out.println(atomicReference.compareAndSet(bigwjz, smallwjz) + "\t" + atomicReference.get().toString());
    }
}

3.2 ABA问题的解决

既然我们不希望修改之前有其他线程改过主物理内存的值那么我们可以这么干，可以使用带版本号的原子引用，每次修改版本号加一这样如果发现虽然开始拿到的主物理内存的值和现在主物理内存的值相等但是版本号不同说明中间被改过，这样就会返回发false，并且不会修改原来的值。

public class ABAslove {
    static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(100,1);

    public static void main(String[] args) {
        new Thread(()->{
            int stamp = atomicStampedReference.getStamp();//获取当前的版本号
            System.out.println(Thread.currentThread().getName() + "\t第一次版本号为" + stamp);
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }//让他睡1秒钟为了让线程2也能拿到相同的版本号
            atomicStampedReference.compareAndSet(100,101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);
            System.out.println(Thread.currentThread().getName() + "\t第二次版本号" + atomicStampedReference.getStamp());
            atomicStampedReference.compareAndSet(101,100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);
            System.out.println(Thread.currentThread().getName() + "\t第三次版本号" + atomicStampedReference.getStamp());
        },"t1").start();
     new Thread(()->{
         int stamp = atomicStampedReference.getStamp();//获取当前的版本号
         System.out.println(Thread.currentThread().getName() + "\t第一次版本号为" + stamp);
         try {
             TimeUnit.SECONDS.sleep(3);
         } catch (InterruptedException e) {
             e.printStackTrace();
         }//让他睡1秒钟为了让线程2也能拿到相同的版本号
         boolean result = atomicStampedReference.compareAndSet(100,2019,stamp,stamp + 1);
         System.out.println(Thread.currentThread().getName() + "\t修改与否：" + result + "\t当前最新实际版本号：" + atomicStampedReference.getStamp());
         System.out.println(Thread.currentThread().getName() + "\t当前实际最新值：" + atomicStampedReference.getReference());
     },"t2").start();
    }
}

看结果

结果显示虽然主物理内存的值仍然是100但是版本号对不上所以更改失败。这样就解决了ABA问题。

林在闪闪发光

关注

12
点赞
踩
20

收藏

觉得还不错? 一键收藏
打赏
19
评论
AQS 和CAS详解

AQS ( Abstract Queued Synchronizer ）是一个抽象的队列同步器，通过维护一个共享资源状态（ Volatile Int State ）和一个先进先出（ FIFO ）的线程等待队列来实现一个多线程访问共享资源的同步框架。
复制链接

扫一扫