2022-04-09 16:55:20

Java中说的CAS(compare and swap)是个啥


CAS(compare and swap)

上一篇文章《大佬们在说的AQS,到底啥是个AQS(AbstractQueuedSynchronizer)同步队列》提到了自旋CAS和volatile,今天讨论下CAS,后天讨论下volatile。

CAS(compare and swap)字面意思是比较和交换,一般还会配合自旋和volatile一起使用,本文讨论CAS,后面文章详细讨论volatile。

为啥需要比较和交换

当我们要操作一个变量的时候,最经典的是自增操作,从1变成2,单线程去操作的时候肯定没问题,但是一旦出现两个线程同时去操作同一个变量的时候,问题就出现了,这与Java的内存模型JMM有关,我放在下一篇文章讨论volatile的时候去讨论,如果线程A已经把变量改为了2,线程B同时去自增操作,没有看到这个变化,还是把变量改为2,两个线程去自增结果应该是3,但结果却是2,这就引入了CAS的方式。也许你觉得加volatile就可以保证修改可见性,但volatile无法保证原子性,下篇文章讨论。

如果使用CAS先比较再交换,就可以解决上面的问题,当线程B去自增的时候,拿着旧的值1和新的值2,要求将变量替换为新值,因为线程A已经修改了变量为2,导致旧值比较的时候不匹配,无法设置,其实就是乐观锁,用经典的原子整型来举例。

乐观锁

顺便提一嘴乐观锁、悲观锁,这个不是具体的一种锁,而是一种思想不仅仅可以用于Java编程,SQL更新的时候也可以用。

  • 乐观锁,比较乐观,认为不一定会发生冲突,所以不排他,允许其他人一起修改,只是在修改前判断一下是否已经被其他人修改过了。

  • 悲观锁,比较悲观,认为一定会发生冲突,所以排他,先上一把锁禁止其他人修改,自己修改完才能释放锁。

原子操作

比较经典的案例是原子整型类AtomicInteger的自增操作getAndIncrement,先看代码:

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

就一行代码,调用了 Unsafe 类,先放一下接着往下看:

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;
}

忘了说valueOffset,这是咋来的呢?valueOffset = unsafe.objectFieldOffset 这样来的,native 方法,不是这篇文件的重点,这个获取对象的内存地址偏移量,不理解也没关系,你可以先理解为内存地址。

通过while进行自旋操作,getIntVolatile 也是 native 方法,就是获取最新的值,最关键的是 compareAndSwapInt,也是 native 方法,想看代码的话,得去看 C++ 的代码了,Hotspot JVM 的源码各位自行查找吧,我只贴出unsafe.cpp关键部分:

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
  UnsafeWrapper("Unsafe_CompareAndSwapInt");
  oop p = JNIHandles::resolve(obj);
  jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
  return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END

看不懂没关系,咱可以猜啊,调用了Atomic::cmpxchg方法,咱再去参观参观:

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;
}

还是看不懂,咱们可以查查大佬们的解释,LOCK_IF_MP是个宏定义,不去研究了,最终拼接出来是指令是 lock cmpxchgl,这又到汇编了,再往下挖就看CPU了,扯远了,先回来。

根据上面的探索,我们可知原子整型类AtomicInteger的操作依赖CAS,而CAS的实现是由Unsafe类实现,Unsafe类又依赖JVM的C++代码实现,C++代码使用汇编让CPU去操作,从而确保操作的原子性和安全性。

Unsafe类

很多大佬的代码跟着跟着就进了Unsafe类,这个类看名字的意思是不安全?

我们使用 Java 代码进行操作的时候,都隔着 JVM,由JVM去替我们操作真实的内存,并且有GC垃圾回收机制去回收内存,所以 Java 是安全的编程语言。

Unsafe类则是不安全的操作,它可以直接操作内存,开辟内存:allocateMemory、扩充内存:reallocateMemory、释放内存:freeMemory、在指定的内存块中设置值:setMemory、未经安全检查的加载Class:defineClass、原子性的更新实例对象指定偏移内存地址的值:compareAndSwapObject、获取系统的负载情况:getLoadAverage等等,所以很危险。

这么危险的操作,我们可以直接用吗?卖个关子,先看正常的使用姿势 Unsafe unsafe = Unsafe.getUnsafe():

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

里面判断了VM.isSystemDomainLoader(var0.getClassLoader()),其实就是判断类加载器是不是为空,如果不为空就抛出异常,啥时候是null呢?只有由启动类加载器(BootstrapClassLoader)加载的class才是null,所以正常情况下是禁止我们直接使用Unsafe类进行不安全操作的,但是,不正常的情况呢?

反射大法好!我们可以通过反射机制,绕过getUnsafe方法拿到:

Class klass = Unsafe.class;
Field field = klass.getDeclaredField("theUnsafe");
field.setAccessible(true);
Unsafe unsafe = (Unsafe) field.get(null);
System.out.println(unsafe.toString());

Unsafe类的使用并不是本文的重点,我也简单带过,我个人的理解这个Unsafe类就是 SUN 公司留的一个“后门”,在Java中可以操作内存,进行不安全的内存使用。

自旋

前面还写到了自旋,自旋也非常的常用,当我们并发更新变量的时候,可能会竞争失败,就需要不断重试。

那为啥不用线程的休眠、唤醒等操作让出CPU呢,在这空转多浪费?

CPU的速度非常快,所以我们的代码执行速度也非常快,占用资源的线程可能一瞬间就执行完成释放资源了,如果再加上线程状态的转换就有点浪费,不如先等一等,自旋等待可能比线程状态切换更快,所以自旋还是有必要的。

那自旋就完美了吗?并不是,在下一篇文章讨论volatile的时候再说自旋的缺点。

ABA问题

CAS虽然看似完美,但还有ABA的问题,假如线程1把变量从A改为B,然后再改为A,线程2通过CAS去修改的时候,旧的变量和现在此时的变量都是A,认为没有人改过,但其实线程1已经改过,这就是ABA问题。

解决ABA问题,其实就是加个版本号,比如AtomicStampedReference,每修改一次就增加版本,这样ABA就被解决了。


商业用途请联系作者获得授权。
版权声明:本文为博主「任霏」原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://www.renfei.net/posts/1003521
评论与留言
以下内容均由网友提交发布,版权与真实性无法查证,请自行辨别。

本站有缓存策略,时间约2小时后能看到您的评论。本站使用自动审核机制,如果您的内容包含广告/谩骂/恐怖/暴力/涉政等不和谐内容将无法展示!


本站有缓存策略,时间约2小时后能看到您的评论。本站使用自动审核机制,如果您的内容包含广告/谩骂/恐怖/暴力/涉政等不和谐内容将无法展示!

关注任霏博客
扫码关注「任霏博客」微信订阅号
微博:任霏博客网
Twitter:@renfeii
Facebook:任霏