全方位探究似懂非懂的 CAS 机制~
Posted TechMerger
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了全方位探究似懂非懂的 CAS 机制~相关的知识,希望对你有一定的参考价值。
前言
求学、面试的时候会无法回避
CAS
话题,但对于其原理,总有种似懂非懂的感觉。
CAS 机制全称: Compare and Swap,即 比较并替换,。也有叫做 Compare and Set 的,即比较并设置。顾名思义,分为两步:
- 比较:读取到了一个值 A,在将其更新为 B 之前,检查原值是否仍为 A
- 替换 / 设置:YES 则将 A 更新为 B,结束;反之,重复上述操作直到成功为止
这种机制在确保原子化操作、实现乐观锁的同时也无法避免一些缺陷,咱们从源码入手分析一下其原理、乐观锁和缺陷等各个细节。
源码解读
以 JDK 中最常用的 AtomicInteger
类的源码为例进行探讨,版本为 JDK 8。
1. Unsafe
首先 AtomicInteger 将通过 Unsafe
提供的静态方法 getUnsafe()
获得其单例。
// java.util.concurrent.atomic.AtomicInteger
public class AtomicInteger extends Number implements java.io.Serializable
private static final Unsafe unsafe = Unsafe.getUnsafe();
...
// jdk.internal.misc.Unsafe
public final class Unsafe
...
private Unsafe()
private static final Unsafe theUnsafe = new Unsafe();
@CallerSensitive
public static Unsafe getUnsafe()
...
return theUnsafe;
为什么叫 Unsafe 呢?
因为它提供了针对任意地址的数据进行不安全读写等内存操作、线程调度、CAS 等操作的入口,如果调用是不受信任的,那么使得代码出错的概率变大,也更会引发 JVM 级别的 exception。
所以要求只有可信任的代码可以获取其单例并进行调用,所以将其命名为 Unsafe,给调用者以提醒。
正因为此,getUnsafe() 内部在返回 Unsafe 单例前会先去检查调用 Class 其是否可信任,如果不是系统 ClassLoader 加载的 Class 的话,会抛出 SecurityException
。
// jdk.internal.misc.Unsafe
public final class Unsafe
...
@CallerSensitive
public static Unsafe getUnsafe()
Class<?> caller = Reflection.getCallerClass();
if (!VM.isSystemDomainLoader(caller.getClassLoader()))
throw new SecurityException("Unsafe");
return theUnsafe;
// sun.misc.VM
public class VM
...
public static boolean isSystemDomainLoader(ClassLoader loader)
return loader == null;
并建议像如下示例代码一样进行使用:
class MyTrustedClass
private static final Unsafe unsafe = Unsafe.getUnsafe();
...
private long myCountAddress = ...;
public int getCount() return unsafe.getByte(myCountAddress);
2. valueOffset & value
其次,赋值内部持有相关变量,包括目标的 int
型数值 value 和关联该 value 地址的 long
型的 valueOffset:
- value 使用
volatile
修饰,默认为 0,反之为 AtomicInteger 构造时指定的初始值 initialValue - valueOffset 是存放 value 的内存相对地址:在 static 块中通过 Unsafe 的 objectFieldOffset() 传入的 value 的 Field 字段得到
// java.util.concurrent.atomic.AtomicInteger
public class AtomicInteger extends Number implements java.io.Serializable
...
private volatile int value;
public AtomicInteger(int initialValue)
value = initialValue;
public AtomicInteger()
private static final long valueOffset;
static
try
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
catch (Exception ex) throw new Error(ex);
// jdk.internal.misc.Unsafe
public final class Unsafe
...
public native long objectFieldOffset(Field f);
Unsafe_ObjectFieldOffset 的实现是调用 find_field_offset 进行,其将进行 Field 的非空检查,以及 Klass 的转化。最后还要转换成 InstanceKlass 实例,并获取其中的 field_offset 并返回。
// unsafe.cpp
UNSAFE_ENTRY(jlong, Unsafe_ObjectFieldOffset(JNIEnv *env, jobject unsafe, jobject field))
UnsafeWrapper("Unsafe_ObjectFieldOffset");
return find_field_offset(field, 0, THREAD);
UNSAFE_END
jint find_field_offset(jobject field, int must_be_static, TRAPS)
if (field == NULL)
THROW_0(vmSymbols::java_lang_NullPointerException());
oop reflected = JNIHandles::resolve_non_null(field);
oop mirror = java_lang_reflect_Field::clazz(reflected);
Klass* k = java_lang_Class::as_Klass(mirror);
int slot = java_lang_reflect_Field::slot(reflected);
int modifiers = java_lang_reflect_Field::modifiers(reflected);
if (must_be_static >= 0)
int really_is_static = ((modifiers & JVM_ACC_STATIC) != 0);
if (must_be_static != really_is_static)
THROW_0(vmSymbols::java_lang_IllegalArgumentException());
int offset = InstanceKlass::cast(k)->field_offset(slot);
return field_offset_from_byte_offset(offset);
// instanceKlass.h
class InstanceKlass: public Klass
...
public:
int field_offset (int index) const return field(index)->offset();
// Casting from Klass*
static InstanceKlass* cast(Klass* k)
assert(k == NULL || k->is_klass(), "must be");
assert(k == NULL || k->oop_is_instance(), "cast to InstanceKlass");
return (InstanceKlass*) k;
3. compareAndSwap
后面是在写值的时候继续调用 Unsafe,关键在于其 native 侧的实现。
比如 compareAndSet()
将传递实例自身,value 的内存相对地址,当前的期待值和目标的更新值四者传递给 Unsafe:
- 返回 false 表示当前的值并非期待值,无法完成更新
- 返回 true 表示更新成功
// java.util.concurrent.atomic.AtomicInteger
public class AtomicInteger extends Number implements java.io.Serializable
private static final long valueOffset;
...
public final boolean compareAndSet(int expect, int update)
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
// jdk.internal.misc.Unsafe
public final class Unsafe
...
public final native boolean compareAndSwapInt(Object o, long offset,
int expected,
int x);
native 的实现是 compareAndSwapInt()
。
- 先通过
JNIHandles
找到 AtomicInteger 实例的地址 oop - 将该 oop 和 value 的相对地址作为参数调用
index_oop_from_field_offset_long()
并得到 value 的内存绝对地址 aadr - 将更新值、addr 和期待值作为参数调用
cmpxchg()
继续
// 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
inline void* index_oop_from_field_offset_long(oop p, jlong field_offset)
jlong byte_offset = field_offset_to_byte_offset(field_offset);
#ifdef ASSERT
if (p != NULL)
assert(byte_offset >= 0 && byte_offset <= (jlong)MAX_OBJECT_SIZE, "sane offset");
if (byte_offset == (jint)byte_offset)
void* ptr_plus_disp = (address)p + byte_offset;
assert((void*)p->obj_field_addr<oop>((jint)byte_offset) == ptr_plus_disp,
"raw [ptr+disp] must be consistent with oop::field_base");
jlong p_size = HeapWordSize * (jlong)(p->size());
assert(byte_offset < p_size, err_msg("Unsafe access: offset " INT64_FORMAT " > object's size " INT64_FORMAT, byte_offset, p_size));
#endif
if (sizeof(char*) == sizeof(jint)) // (this constant folds!)
return (address)p + (jint) byte_offset;
else
return (address)p + byte_offset;
cmpxchg() 的实现在 atomic.cpp 中,其中 value 的地址用 volatile 关键字描述,意味着目标数据的变化将立即反映到内存、并要求读取时应当从内存中取出。
- 首先计算得到 value 地址的当前数值,即 cur_as_bytes[offset]
- 假使当前数值等于期待值 compare_value:
- 调用
cmpxchg
CPU 指令将 dest_int 地址对应的数值执行期待值为 cur,更新值为 new_val 的 CAS 操作 - 该操作返回的是期待值的话,表示更新成功,跳过循环并返回期待值。
Unsafe_CompareAndSwapInt()
将收到匹配期待值的结果,并向 Java 侧返回 true - 反之,将 cur 更新为 CPU 指令返回的当前值,再继续下一次循环,直到成功为止
- 调用
- 反之即不等于期待值,直接返回
Unsafe_CompareAndSwapInt()
将收到不匹配期待值的结果,并向 Java 侧返回 false
// atomic.cpp
jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte* dest, jbyte compare_value)
uintptr_t dest_addr = (uintptr_t)dest;
uintptr_t offset = dest_addr % sizeof(jint);
volatile jint* dest_int = (volatile jint*)(dest_addr - offset);
jint cur = *dest_int;
jbyte* cur_as_bytes = (jbyte*)(&cur);
jint new_val = cur;
jbyte* new_val_as_bytes = (jbyte*)(&new_val);
new_val_as_bytes[offset] = exchange_value;
while (cur_as_bytes[offset] == compare_value)
jint res = cmpxchg(new_val, dest_int, cur);
if (res == cur) break;
cur = res;
new_val = cur;
new_val_as_bytes[offset] = exchange_value;
return cur_as_bytes[offset];
事实上,android 中 AtomicInteger
的实现稍稍不同,没有只用 Unsafe 而是采用了 VarHandle
,这里不再展开。
// android/libcore/ojluni/src/main/java/java/
// util/concurrent/atomic/AtomicInteger.java
public class AtomicInteger extends Number implements java.io.Serializable
...
public final boolean compareAndSet(int expectedValue, int newValue)
// Android-changed: Using VarHandle instead of Unsafe
// return U.compareAndSetInt(this, VALUE, expectedValue, newValue);
return VALUE.compareAndSet(this, expectedValue, newValue);
乐观锁
利用 CAS 机制可以实现一个乐观锁,即无需加锁可实现多个线程同时读取、但是仅有一个线程可以成功写入数据,并导致其他要卸乳数据的线程回滚重试。
例如 Unsafe 通过上述的 compareAndSwapInt()
实现的自增 1 的原子操作的逻辑。
// java.util.concurrent.atomic.AtomicInteger
public class AtomicInteger extends Number implements java.io.Serializable
...
public final int getAndIncrement()
return unsafe.getAndAddInt(this, valueOffset, 1);
// jdk.internal.misc.Unsafe
public final class Unsafe
...
public final int getAndAddInt(Object o, long offset, int delta)
int v;
do
v = getIntVolatile(o, offset);
while (!compareAndSwapInt(o, offset, v, v + delta));
return v;
因为整个过程中不涉及加/解锁的操作,乐观锁也被称为无锁编程。
本质上说,乐观锁其实不是“锁”,它仅仅是一个循环重试 CAS 的算法而已!
缺陷
CAS 机制可以高效地实现原子操作,但仍不完美:
-
循环时间长开销大:CAS 大量失败后长时间占用 CPU 资源,加大了系统性能开销
-
只能保证一个共享变量的原子操作:当对一个共享变量执行操作时,我们可以使用循环 CAS 的方式来保证原子操作,但是对多个共享变量操作时,循环 CAS 就无法保证操作的原子性
-
ABA 问题:CAS 机制本质上依赖值有没有发生变化的操作条件。但是如果值原来是 A、被改成变成了 B、最后又变回了 A,那么使用 CAS 进行检查时会发现它的值没有发生变化进行了操作,但是实际上却变化了,这其实违背了约定的条件。
Java 1.5 开始提供了一个类AtomicStampedReference 来解决该问题,其提供的 compareAndSet() 会首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,才进行值的更新操作
结语
可以看到无论是初始化还是写值都是通过 Unsafe 调度完成,整理了如下的流程图以加深理解:
-
AtomicInteger
通过静态方法getUnsafe()
获得Unsafe
实例 -
接着通过 Unsafe 实例的 native 方法
objectFieldOffset()
传入使用volatie
修饰的数值 value 的 Field 字段得到其内存相对地址 -
关键的
compareAndSet()
亦由 Unsafe 调度,即 native 方法compareAndSwapInt()
。主要是传入 AtomicInteger 实例,value 内存相对地址,期待值以及更新值。native 的实现由
atomic.cpp
的cmpxchg()
完成,当前 value 内存地址返回的值匹配期待值的话,执行更新操作;反之,直接返回 false。执行更新的操作采用
cmpxchg
CPU 指令,如果得到的值不符合期待值的话,更新期待值继续下一次循环,直到匹配为止。
参考文章
以上是关于全方位探究似懂非懂的 CAS 机制~的主要内容,如果未能解决你的问题,请参考以下文章