原文来自于：https://zha-ge.cn/java/66

面试官最爱刁难：说说 CAS 原理，答不好直接淘汰

哎，这事儿说出来也不怕丢人，前阵子面了家自诩“大厂气质”的公司。面试的时候，原地就跟我开大，“CAS原理说说，别光讲表面的！”咱说心里话，这玩意儿，简历上写过、博客里唠过，也见过场面，但真遇到面试官“灵魂追问”，心里还是有点慌。

其实我一开始对CAS的理解，说白了就那点皮毛：比较并交换嘛，等价于“俩小哥抢座位，谁抢到了就占了，没抢到的乖乖回来重试”。但面试官这架势肯定要继续刨，我只好强撑着例子往下讲。

一碗奶茶引发的并发风波

先来个场景，比代码更带感：

• 五个人围着一桶珍珠奶茶，谁都想先喝一口。
• 但是规定：只有当前“奶茶桶”状态还是满的时候，你这口操作才能生效，否则回炉重来。
• 比如A和B同时试图Update奶茶状态，A手快了一步，B就得怏怏而归，换一波尝试。典型的CAS了不是？

程序里一般是AtomicXXX家族，CAS的大杀器，像这样：

AtomicInteger stock = new AtomicInteger(1);
// ...
if (stock.compareAndSet(1, 0)) {
    // 飙戏：我喝到奶茶了
}
// ...

用compareAndSet，传入期望值和新值，只有当前值还等于期望值，才会成功“占有奶茶”，否则白忙一局。

比起sychronized那种“一把大锁敲死”，CAS算是锦上添花的优化——无锁，不堵队！

踩坑瞬间

这才是重点——跟面试官扯玄学之前，得先吐槽一下CAS翻车现场。不知道你踩过没有，反正我肯定有：

• ABA问题：本以为A->B就是变了，谁知道变量A还可以莫名其妙又变回来，你的CAS也没察觉到！真实场景下就是：变量先从1变0又被改回1，CAS还天真觉得“一切未变”。
  • 解决思路？加版本号！AtomicStampedReference走起。
• 自旋太浪费CPU：碰上大并发，CAS失败太多，会在那里死循环一样“自旋”重试，这CPU占用直线上升，工程师在旁边喝两壶咖啡。
• 只能操作一个变量：要是你想原子操作多个字段？抱歉，CAS直说“管不着”，还得依赖更复杂的东西（比如锁或者新一代的VarHandle啦）。

说多了都是泪，谁还没被CAS坑过？

为啥Java的CAS能跑这么快

这里，老实说我也被面试官问呆过。他问：Java怎么保证CAS底层原子性的？
我的内心OS如表：

把底层“硬件原子操作”搬到Java应用层，你除了感叹还是感叹。

经验启示

• 场合要用对：低并发、高争抢量下，CAS效果杠杠的。可千万别傻乎乎所有场合一把梭。
• 留意ABA漏洞：“加版本号”不只是项目经理喜欢，某些业务场景真不能省。
• 非万能：需要一次性更新多变量时，还是得别的方案兜底。
• 避免无脑自旋：重试次数太高的地方，哪怕你CPU再猛也扛不住，适配点指数退避、限重试，别让服务器哭出来。

说白了，CAS是“无锁利器”的招牌，但想把他端上大厂生产环境，还得整点人情世故。
你要是真在面试碰上CAS挖坑，别慌，信仰加源码两把抓，“一口老血”的自嘲精神，未必就不会翻盘。

唠到这儿，也累了。码代码也别太教条，偶尔吐槽两句，你懂的：技术路上，大家都互相踩过CAS的坑。收！