Java中Unsafe类的CAS操作是并发原子类的核心机制，通过CPU指令实现硬件级原子性；其compareAndSwap*方法基于内存偏移量比较并更新值；需反射获取实例但JDK9+后受限；存在ABA、自旋开销等局限，应优先使用java.util.concurrent.atomic封装类。
Java 中 Unsafe 类提供的 CAS（Compare-And-Swap）操作是 java.util.concurrent 包底层原子类（如 AtomicInteger、AtomicReference）的核心实现机制。它直接调用 CPU 级别的原子指令（如 x86 的 CMPXCHG），绕过 JVM 同步锁，在硬件层面保证操作的原子性。
Unsafe 的 CAS 方法签名与作用
Unsafe 提供了多个以 compareAndSwap* 开头的方法，最常用的是：
compareAndSwapInt(Object obj, long offset, int expectedValue, int newValue)compareAndSwapLong(Object obj, long offset, long expectedValue, long newValue)compareAndSwapObject(Object obj, long offset, Object expectedValue, Object newValue)
这些方法语义一致：检查对象 obj 在内存偏移量 offset 处的当前值是否等于 expectedValue；若相等，则原子地将其更新为 newValue，并返回 true；否则不修改，返回 false。
获取 Unsafe 实例的典型方式（非标准但常见）
Unsafe 是受限类，JDK 不允许直接通过 new Unsafe() 或公开构造器获取。主流做法是利用反射访问其静态私有字段 theUnsafe：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe) f.get(null);
⚠️ 注意：JDK 9+ 引入模块系统后，需添加 JVM 参数（如 --add-opens java.base/jdk.internal.misc=ALL-UNNAMED）才能绕过模块限制；JDK 17+ 进一步收紧，默认禁止反射访问 Unsafe，生产环境应避免直接使用。
手动实现一个简易 AtomicInteger（演示 CAS 逻辑）
以下代码展示如何用 Unsafe 模拟 AtomicInteger.incrementAndGet() 的核心逻辑：
public class SimpleAtomicInteger {
private volatile int value;
private static final long VALUE_OFFSET;
private static final Unsafe UNSAFE;
static {
try {
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
UNSAFE = (Unsafe) f.get(null);
VALUE_OFFSET = UNSAFE.objectFieldOffset(
SimpleAtomicInteger.class.getDeclaredField("value"));
} catch (Exception e) {
throw new Error(e);
}
}
public final int incrementAndGet() {
int current;
do {
current = value; // volatile 读，确保看到最新值
} while (!UNSAFE.compareAndSwapInt(this, VALUE_OFFSET, current, current + 1));
return current + 1;
}
}
关键点说明：
-
objectFieldOffset获取value字段在对象内存中的偏移地址，这是 CAS 操作的定位依据 - 使用
volatile修饰value，配合compareAndSwapInt实现“读-改-写”原子性 - 循环重试（CAS 自旋）是必要策略：失败说明其他线程已抢先修改，需重新读取再尝试
CAS 的局限性与 ABA 问题
CAS 虽高效，但存在天然缺陷：
-
ABA 问题：某值从 A → B → A，CAS 会误判为“未被修改”，但实际上中间状态已变。解决方式通常是引入版本号（如
AtomicStampedReference） - 自旋开销：高竞争下反复失败会导致 CPU 空转，影响性能
-
只能保证单变量原子性：对多个字段的复合操作仍需借助锁或
AtomicReference<Object>封装整个状态
实际开发中，应优先使用 java.util.concurrent.atomic 提供的成熟类，而非手写 Unsafe 逻辑——它们已针对不同 JDK 版本做了兼容与优化。
