深入掌握底层源码常见的 CAS 原子编程

用户头像
malt
关注
发布于: 2020 年 11 月 29 日
深入掌握底层源码常见的 CAS 原子编程

前言



如果要聊原子类相关的话题, 可以先从基本的概念开始



1、原子类为了解决什么样的问题?



答: 为了解决并发场景下无锁的方式保证单一变量的数据一致性



2、什么情况下存在并发问题?



答: 多个线程同时读写同一个共享数据时存在多线程并发问题



解决并发安全问题的方式有很多种方式, 著名的就是 JDK 并发包 concurrent, 为了并发而存在的



阅读文章收获如下知识:



- 无锁编程产出背景

- CAS 如何实现的无锁编程

- CAS 使用中的 “ABA” 痛点

- 如何解决 “ABA” 问题



文章首发自公众号 【源码兴趣圈】,关注公众号第一时间获取后端硬核知识,已发布 【44】篇 原创技术博文



非原子计算



大家应该都知道, 类似于代码中的 i++ 操作, 虽然是一行, 但是执行时候是分为三步的



  • 从主存获取变量 i

  • 变量i值+1

  • 新增后变量i值写回主存



写个小程序来更好的理解, 不论我们怎么运行下方程序, 99% 以上概率不会到达 100000000



static int NUM = 0;
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 10000; i++) {
new Thread(() -> {
for (int j = 0; j < 10000; j++) {
NUM++;
}
}).start();
}
Thread.sleep(2000);
System.out.println(NUM);
/**
* 99149419
*/
}



可以使用 JDK 自带的 synchronized, 通过 互斥锁的方式 同步执行 NUM++ 这个代码块



static int NUM = 0;
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 10000; i++) {
new Thread(() -> {
for (int j = 0; j < 10000; j++) {
synchronized (Object.class) {
NUM++;
}
}
}).start();
}
Thread.sleep(2000);
System.out.println(NUM);
/**
* 100000000
*/
}



前面一直在说锁, 写着 AtomicInteger 在这说锁的问题, 咱不能挂着羊皮卖狗肉是吧





如果看过 JDK 源码 JUC 包下的类库源代码, 关于 Atomic 开头的类库 应该不会陌生



Atomic 英 [əˈtɒmɪk] 美 [əˈtɑːmɪk] 翻译 : 原子的



如果不使用锁来解决上面的非原子自增问题, 可以这么来写



static AtomicInteger NUM = new AtomicInteger();
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 10000; i++) {
new Thread(() -> {
for (int j = 0; j < 10000; j++) {
// 🚩 重点哦, 自增并获取新值
NUM.incrementAndGet();
}
}).start();
}
Thread.sleep(2000);
System.out.println(NUM);
/**
* 100000000
*/
}



AtomicInteger 简介



看到一个技术点或者框架之类比较新颖的知识, 一般会思考两个问题



它是什么



AtomicInteger 是 JDK 并发包下提供的 操作 Integer 类型原子类, 通过调用底层 Unsafe 的 CAS 相关方法实现原子操作



基于乐观锁的思想实现的一种无锁化原子操作, 保障了多线程情况下单一变量的线程安全问题



关于 CAS 的概念下面会详细说明



有什么优点



AtmoicInteger 使用硬件级别的指令 CAS 来更新计数器的值, 机器直接支持的指令, 这样可以避免加锁



比如像互斥锁 synchronized 在并发比较严重情况下, 会将锁 升级到重量级锁



唤醒与阻塞线程时会有一个 用户态到内核态的一个转变, 而转换状态是需要消耗很多时间的



写过程序进行测试, 尽管 synchronized 经过升级后, 性能有了大幅度提升, 但在 一般并发场景下, CAS 无锁算法性能更高一些



当然不可能会有尽善尽美的存在, 关于 CAS 无锁算法会在下面说明劣势所在



结构分析



AtomicInteger 有两个构造方法, 分别是一个无参构造及有参构造



  • 无参构造的 value 就是 int 的默认值 0

  • 有参构造会将 value 赋值



public AtomicInteger() { }
public AtomicInteger(int initialValue) {
value = initialValue;
}



AtomicInteger 有三个重要的变量, 分别是:



Unsafe: 可以理解它对于 Java 而言, 是一个 "BUG" 的存在, 在 AtomicInteger 里的最大作用就是直接操作内存进行值替换



value: 使用 int 类型存储 AtomicInteger 计算的值, 通过 volatile 进行修饰, 提供了内存可见性及防止指令重排序



valueOffset: value 的内存偏移量



// 获取Unsafe实例
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
// 静态代码块,在类加载时运行
static {
try {
// 获取 value 的内存偏移量
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) {
throw new Error(ex);
}
}
private volatile int value;



这里罗列出一些常用API, 核心实现思路都是一致的, 会着重讲其中一个



// 获取当前 value 值
public final int get();
// 取当前的值, 并设置新的值
public final int getAndSet(int newValue);
// 获取当前的值, 并加上预期的值
public final int getAndAdd(int delta);
// 获取当前值, 并进行自增1
public final int getAndIncrement();
// 获取当前值, 并进行自减1
public final int getAndDecrement();



获取当前值并自增 #getAndIncrement()



看一下具体在源码中是如何操作的



public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
/**
* unsafe.getAndAddInt
*
* @param var1 AtomicInteger 对象
* @param var2 value 内存偏移量
* @param var4 增加的值, 比如在原有值上 + 1
* @return
*/
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
// 内存中 value 最新值
var5 = this.getIntVolatile(var1, var2);
} while (!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}



这里就是 CAS 体现无锁算法的地方, 先来说下这段代码的执行步骤



1、根据 AtomicInteger 对象 以及 value 内存偏移量获取对应 value 最新值



2、通过 compareAndSwapInt(...) 将内存中的值(var5)更改为期望的值 (var5+var4), 不存在多线程竞争成功修改返回 True 结束循环, Flase 继续执行循环



精髓的地方就在于 compareAndSwapInt(...)



/**
* 比较 var1 的 var2 内存偏移量处的值是否和 var4 相等, 相等则更新为 var5
*
* @param var1 AtomicInteger 对象
* @param var2 value 内存偏移量
* @param var4 value 原本的值
* @param var5 期望将 value 设置的值
* @return
*/
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);



由于是 native 关键字修饰, 我们无法查看其源码, 说明一下方法思路



1、通过 var1(AtomicInteger) 获取到 var2 (内存偏移量) 的 value 值



2、将 value(内存中值) 与 var4(线程内获取的value值) 进行比较



3、如果相等将 var5(期望值) 设置为内存中新的 value 并返回 True



4、不相等返回 False 继续尝试执行循环



图文分析 CAS



这里给出一组图片进一步理解 CAS



Unsafe#getAndAddInt() 以此方法为例



1、这个图片相当于 AtomicInteger 对象对应的 valueOffset 位置





2、线程一执行 var5 = this.getIntVolatile(var1, var2)





3、线程二执行 var5 = this.getIntVolatile(var1, var2)



此时在线程一、二的工作内存中 var5 都是 0





4、线程一欲修改内存中的 value 为1, 通过比对 var4 与内存中的值相等, 内存值成功被设置成 1





5、线程二也是要修改内存中对应的 value 值, 发现已经不相等了, 返回 False 继续尝试修改





不足之处



CAS 虽然能够实现无锁编程, 在一般情况下对性能做出了提升, 但是并不是没有局限性或缺点



1、CPU 自旋开销较大



在高并发情况下, 自旋 CAS 如果长时间不成功, 会给 CPU 带来非常大的执行开销



如果是实现高并发下的计数, 可以使用 LongAdder, 设计的高并发思想真的强!



2、著名的 "ABA" 问题



CAS 需要在操作值的时候检查下值有没有发生变化, 如果没有发生变化则更新



但是如果一个值原来是A, 变成了B, 又变成了A, 那么使用 CAS 进行检查时会发现它的值没有发生变化, 但是实际上却变化了



如果感兴趣的小伙伴可以去看下 JUCA 原子包下的 AtomicStampedReference



ABA 问题背景



AtomicInteger 存在的一个问题, 也是大部分 Atomic 相关类存在的, 就是 ABA 问题



简短来说, 就是线程一获取到 AtomicInteger 的 value 为 0, 在准备做修改之前



线程二对 AtomicInteger 的 value 做了两次操作, 一次是将值修改为 1, 然后又将值修改为原来的 0



此时线程一进行 CAS 操作, 发现内存中的值依旧是 0, OK, 更新成功, 结合下图了解





1、为什么线程二能够在线程一获取最新值后进行操作?



我们以 AtomicInteger#getAndIncrement 说明



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



因为我们的 CPU 执行是 抢占式的, 时间片分配并不固定



可能在线程一读取完标记1处之后, 时间片就分配执行了线程二, 此时线程一等待时间片的分配



等线程二做完两步操作之后, 时间片分配到线程一, 这时才会继续执行



2、ABA 会引发什么样的问题?



大家应该都知道了 ABA 的行为是如何发生的, 列举网上的一个小例子, 大致意思如下:



1、小明银行卡账户余额1万元, 去取款机取钱5千元, 正常应该发起一次请求, 因为网络或机器故障发起了两次请求



各位大哥大姐不要抬杠哈, 不要说什么后端接口幂等, 取款机防重复提交之类的, 例子是为了说明问题, 感谢 😄



2、线程一「由取款机发起」: 获取当前银行卡余额值1万元, 期望值5千元



3、线程二「由取款机发起」: 获取当前银行卡余额值1万元, 期望值5千元



4、线程一成功了, 银行卡内余额剩余五千, 线程二未分配时间片, 获取到余额后被阻塞



5、此时线程三「支付宝转入银行卡」: 获取当前银行卡余额5千元, 期望值1万元, 修改成功



6、线程二获得时间片, 发现卡内余额是1万, 成功将卡内余额减少至5千



7、卡内余额原本应是1万-5千+5千=1万, 最终因为 ABA 问题导致 1万-5千+5千-5千=5千



当然正式业务中, 可能不会存在此类问题, 不过平常自己业务中使用到了原子类, 还是会埋下潜在隐患



我们先通过小程序代码来看下, ABA 问题是如何复现的



public static void main(String[] args) throws InterruptedException {
AtomicInteger atomicInteger = new AtomicInteger(100);
new Thread(() -> {
atomicInteger.compareAndSet(100, 101);
atomicInteger.compareAndSet(101, 100);
}).start();
Thread.sleep(1000);
new Thread(() -> {
boolean result = atomicInteger.compareAndSet(100, 101);
System.out.println(String.format(" >>> 修改 atomicInteger :: %s ", result));
}).start();
/**
* >>> 修改 atomicInteger :: true
*/
}



1、创建一个初始值为100的 AtomicInteger, 线程一将100-> 101, 再从101->100



2、休眠1000ms, 防止时间片分配线程二提前执行



3、线程二从100->101, 修改成功



AtomicStampedReference



先来说下解决 ABA 的思路吧, 也就是 AtomicStampedReference 的原理



内部维护了一个 Pair<T> 对象, 存储了 value 值和一个版本号, 每次更新除了 value 值还会更新版本号



private static class Pair<T> {
// 存储值, 相当于上文的值100
final T reference;
// 类似于版本号的概念
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
// 创建一个新的Pair对象, 每次值变化时都会创建一个新的对象
static <T> AtomicStampedReference.Pair<T> of(T reference, int stamp) {
return new AtomicStampedReference.Pair<T>(reference, stamp);
}
}



我们还是先通过一个小程序来了解下 AtomicStampedReference 运行机制



@SneakyThrows
public static void main(String[] args) {
AtomicStampedReference stampedReference = new AtomicStampedReference(100, 0);
new Thread(() -> {
Thread.sleep(50);
stampedReference.compareAndSet(100,
101,
stampedReference.getStamp(),
stampedReference.getStamp() + 1);
stampedReference.compareAndSet(101,
100,
stampedReference.getStamp(),
stampedReference.getStamp() + 1);
}).start();
new Thread(() -> {
int stamp = stampedReference.getStamp();
Thread.sleep(500);
boolean result = stampedReference.compareAndSet(100, 101, stamp, stamp + 1);
System.out.println(String.format(" >>> 修改 stampedReference :: %s ", result));
}).start();
/**
* >>> 修改 atomicInteger :: false
*/
}



1、创建 AtomicStampedReference, 并设置初始值100, 以及版本号0



2、线程一睡眠50ms, 然后对value做出操作100->101, 101->100, 版本+1



为什么要睡眠50ms? 为了模拟多线程并发抢占, 让线程二先获取到版本号



3、线程二睡眠500ms, 等待线程一执行完毕, 开始将100->101, 版本号+1



不出意外, 线程二一定会修改失败, 虽然值相对应, 但是预期的版本号与 Pair 中的已不一致



compareAndSet



来看下它的 compareAndSet(...) 是如何做的



/**
* 比较并设置
*
* @param expectedReference 预期值
* @param newReference 期望值
* @param expectedStamp 预期版本号
* @param newStamp 期望版本号
* @return 是否成功
*/
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
// 获取当前 pair 引用
AtomicStampedReference.Pair<V> current = pair;
// 预期值对比 pair value
return expectedReference == current.reference &&
// 预期版本号对比 pair stamp
expectedStamp == current.stamp &&
// 期望值对比 pair value
((newReference == current.reference &&
// 期望版本号对比 pair stamp
newStamp == current.stamp) ||
// casPair
casPair(current, Pair.of(newReference, newStamp)));
}



如果 compareAndSet(...) 为 True, 必须满足上述条件表达式中3个条件



1、预期值等于 pair value



2、预期版本号等于 pair stamp



3、期望值等于 pair value 并且期望版本号等于 pair stamp



这是 value 和 版本号未发生变化时的场景



4、当第一个条件和第二个条件满足, 但是不满足第三个条件, 证明值和版本号发生了变化, 创建 Pair 进行 CAS 比较替换



上述条件必须满足1、2、3或者满足1、2、4均可返回 True



将当前 Pair 原子引用切换为新 Pair, 与 AtomicReference 思路一致, 将对象引用进行原子转换



private boolean casPair(AtomicStampedReference.Pair<V> cmp, AtomicStampedReference.Pair<V> val) {
return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val);
}



使用 Integer value 的坑



小伙伴应该都知道, 如果你写出下面的代码, 是不会在堆内创建对象的



Integer i1 = 100;
Integer i2 = 101;



因为 JVM 会在常量池内存储两个对象, 而超过 -128~127 的数值则会在堆中创建对象



我们 Pair 对象的 reference 是范型, 传递的 int 类型的数值会被转型, 变为 Integer



使用 Integer 类型并且值不在 -128~127 范围内, 会出现数据比对出错的情况, 大家看一下 compareAndSet(...) 就明白了



AtomicMarkableReference



大家看到上面的版本号两次操作必须保持不一致, 得自增或、自减或者别的操作, 相对而言也比较繁琐



Doug Lea 大师同时也为我们提供了一个省事的类库 AtomicMarkableReference



API 接口以及实现思路与上述的基本一致, 只不过把版本号 int 类型替换为了 boolean 类型, 其它无区别



不过, AtomicMarkableReference 并不能完全解决 ABA 问题, 只是能够小概率预防



结言



由于作者水平有限, 欢迎大家能够反馈指正文章中错误不正确的地方, 感谢 🙏



小伙伴的喜欢就是对我最大的支持, 如果读了文章有所收获, 希望能够 点赞、评论、关注三连!



推荐阅读:





作者麻花,坐标帝都 Java 后端研发,励志成为架构师的一枚处女座程序员,专注高并发、框架底层源码、分布式等知识分享



发布于: 2020 年 11 月 29 日阅读数: 284
用户头像

malt

关注

微信公众号:源码兴趣圈 2018.11.17 加入

坐标帝都一枚普通程序员,主攻 Java 语言,也会使用 Python、GO 写脚本,专注与高并发、框架底层源码、分布式等知识分享

评论

发布
暂无评论
深入掌握底层源码常见的 CAS 原子编程