Java 中 CAS 怎么利用 CPU 的 cmpxchg 指令在多核架构下实现总线锁与缓存锁-java教程-PHP中文网

cas的原子性由cpu硬件指令直接保障，java通过unsafe类调用jvm底层atomic::cmpxchg函数，在x86上生成lock cmpxchg指令，现代cpu优先依赖mesi缓存一致性协议实现缓存锁，仅在跨缓存行或不可缓存时退化为总线锁。

java 中 cas 怎么利用 cpu 的 cmpxchg 指令在多核架构下实现总线锁与缓存锁

CAS（Compare-And-Swap）在 Java 中并非直接调用 CPU 的 cmpxchg 指令，而是通过 JVM 底层的原子类（如 Unsafe.compareAndSwapInt）间接触发，其硬件实现依赖于 x86 架构下的 cmpxchg 指令——该指令天然具备原子性，但具体如何保证多核一致性，关键不在于“总线锁”或“缓存锁”的显式选择，而在于 CPU 对该指令执行时的自动协同机制。

cmpxchg 本身不主动加锁，靠硬件协议保障原子性

cmpxchg 是一条带有隐含锁语义的指令：当它被用于内存操作（如 cmpxchg [rax], ebx）时，CPU 会在执行期间自动确保该内存地址的读-改-写过程不被其他核心中断。这种保证不是靠软件申请“总线锁”，也不是程序员手动控制“缓存锁”，而是由 CPU 微架构和缓存一致性协议（如 MESI）协同完成：

若目标地址所在缓存行处于本核的 Exclusive 或 Modified 状态，cmpxchg 可直接在本地缓存完成，无需总线信号——这等效于“缓存锁”效果；
若该缓存行在其他核上为 Shared 或 Invalid，CPU 会通过 MESI 协议发起总线/互连请求（如 RFO，Request For Ownership），强制其他核将对应缓存行置为 Invalid，再独占写入——这个过程对上层透明，但本质是缓存一致性协议驱动的“缓存行级锁定”；
只有在极老的奔腾或不支持缓存一致性的系统中，才可能退化为真正阻塞整条总线的 LOCK# 信号（即传统“总线锁”），现代 x86 CPU 几乎从不这么做。

JVM 的 Unsafe 实现桥接了指令与平台差异

Java 程序无法直接发出 cmpxchg，而是调用 Unsafe.compareAndSwapXxx 方法。JVM 在不同 CPU 架构上生成对应汇编：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

x86_64 下，HotSpot JVM 编译后实际生成带 lock cmpxchg 前缀的指令（lock 前缀确保指令在多核下原子执行，并触发缓存一致性协议）；
ARM 或 AArch64 下，则使用 ldaxr/stlxr 这类加载-存储排他指令对，配合底层 exclusive monitor 实现等价语义；
JVM 层屏蔽了这些细节，开发者只需关注逻辑正确性，不用关心锁粒度是总线还是缓存行。

为什么不会出现“两个核心同时成功 CAS”？

根本原因在于 cmpxchg 是 CPU 提供的原子读-改-写原语：它把“读取旧值、比较是否相等、写入新值”三步压缩为一个不可分割的操作。即使两个核心在同一纳秒发起对同一地址的 cmpxchg，硬件也会串行化执行——其中一个获得缓存行所有权并成功，另一个因缓存行状态冲突而失败（返回 false）。这不是靠锁排队，而是靠缓存一致性协议+指令原子性双重保障。