CAS不是锁，而是通过CPU指令（如x86的cmpxchg）原子执行“比较+交换”，实现无锁原子更新；它适用于高读低写场景，但存在ABA问题、自旋开销大和仅支持单变量等局限。
CAS（Compare-and-Swap）不是靠“背概念”掌握的，关键在理解它为什么存在、怎么被调用、以及在哪种并发场景下真正起效。下面直击核心，分三步讲清楚。
一、先搞懂 CAS 解决什么问题
多线程环境下，多个线程同时修改一个共享变量（比如计数器），容易出现“读-改-写”中间被插队，导致结果丢失。传统用 synchronized 加锁能解决，但有阻塞开销和上下文切换成本。
CAS 是一种无锁（lock-free）方案：它不阻塞线程，而是靠硬件指令（如 x86 的 cmpxchg）原子性地完成“比较+更新”。只有当前值等于预期值时，才把新值写入；否则重试。
- 典型例子：
AtomicInteger.incrementAndGet()底层就是循环调用 CAS，直到成功 - 注意：CAS 不是万能的——它只保证单个变量的原子性，不能直接保护一段逻辑
二、动手看懂底层怎么跑起来
Java 中 CAS 的入口在 Unsafe 类，它是 JVM 提供的“后门”，允许直接操作内存地址。虽然不建议直接用，但理解它才能看清本质：
立即学习“Java免费学习笔记（深入）”；
-
Unsafe.compareAndSwapInt(obj, offset, expect, update)：对对象某字段（按内存偏移量）执行整型 CAS - 所有
java.util.concurrent.atomic包下的类（AtomicLong、AtomicReference等）都基于它封装 - 你可以用
javap -c AtomicInteger查看字节码，会看到对Unsafe方法的调用
三、避开三个典型陷阱
学 CAS 容易卡在“知道但不会用”，往往是因为没踩过这些坑：
-
ABA 问题：变量从 A→B→A，CAS 误判为“没变”。解决方案：用
AtomicStampedReference带版本号校验 -
自旋开销大：高竞争下反复失败重试，浪费 CPU。对策：结合退避策略（如
Thread.yield()或指数退避） -
只能单变量：想原子更新两个字段？得用
AtomicReference<pair></pair>封装成对象，或改用锁
不复杂但容易忽略：CAS 的威力不在单次操作，而在它支撑了 ConcurrentHashMap、LinkedTransferQueue 这些高性能并发容器的实现逻辑。真正突破，是从“会调 API”转向“能看懂它们怎么靠 CAS 组装出无锁结构”。
