从AtomicInteger到自旋锁：深入剖析CAS的实战演进与性能调优
1. 从AtomicInteger看CAS的底层原理
我第一次接触CAS是在使用AtomicInteger的时候。当时需要做一个简单的计数器，多个线程同时累加，用synchronized太重，volatile又不够，同事推荐我用AtomicInteger。说实话，刚开始看到这个类的性能比synchronized高几十倍，我是持怀疑态度的。
AtomicInteger的核心就是CAS操作。比如我们常用的incrementAndGet()方法，表面看就是个简单的+1操作，但底层其实是这样的：
public final int incrementAndGet() { return unsafe.getAndAddInt(this, valueOffset, 1) + 1; }再往深处挖，会发现它调用了Unsafe类的compareAndSwapInt方法。这个方法就是CAS的Java实现，它的工作流程特别有意思：
- 先读取当前值V
- 计算新值N（比如V+1）
- 比较当前内存中的值是否还是V
- 如果是就更新为N，否则重试
这个过程就像我们去超市寄存行李：先记住柜子编号（V），取包时如果柜子编号没变（还是V），就取走行李（更新为N）；如果发现柜子编号变了（被别人动过），就重新开始流程。
2. 手把手实现一个自旋锁
理解了CAS的原理后，我决定自己实现一个最简单的自旋锁。这个锁的特点是：获取不到锁的线程不会阻塞，而是不断重试。
先定义锁的状态：
- 0表示锁空闲
- 1表示锁被占用
核心代码非常简单：
public class SimpleSpinLock { private AtomicInteger state = new AtomicInteger(0); public void lock() { while (!state.compareAndSet(0, 1)) { // 自旋等待 } } public void unlock() { state.set(0); } }这个实现虽然简单，但在实际测试中我发现几个问题：
- 竞争激烈时CPU占用率会飙升
- 长时间自旋会导致线程饥饿
- 没有重入机制
3. 性能调优实战：从简单自旋到智能退避
针对上面发现的问题，我做了几个优化方案：
3.1 限制自旋次数
最简单的优化是限制最大自旋次数：
public boolean tryLock(int maxSpins) { for (int i = 0; i < maxSpins; i++) { if (state.compareAndSet(0, 1)) { return true; } } return false; }3.2 指数退避策略
更高级的做法是引入退避算法，类似TCP的重传机制：
public void lock() { int backoff = 1; while (!state.compareAndSet(0, 1)) { for (int i = 0; i < backoff; i++) { Thread.yield(); } backoff = Math.min(backoff * 2, MAX_BACKOFF); } }3.3 混合策略
在实际项目中，我最终采用的是混合策略：
- 前100次快速自旋
- 之后每次自旋后yield
- 超过1ms后转为阻塞
4. 生产环境中的最佳实践
经过多次压测和线上验证，我总结了几个关键经验：
- 短任务优先：自旋锁最适合保护耗时<1ms的临界区
- 核数相关：自旋次数建议设置为CPU核心数的2-3倍
- 监控必备：必须监控锁的等待时间和自旋次数
- 混合使用：可以结合synchronized，在自旋失败后转为阻塞
一个生产级的实现还需要考虑：
- 锁重入
- 公平性
- 死锁检测
- 线程中断处理
比如我们线上使用的改进版：
public boolean tryLock(long timeout, TimeUnit unit) { long start = System.nanoTime(); long timeoutNs = unit.toNanos(timeout); int spins = 0; while (!state.compareAndSet(0, 1)) { if (System.nanoTime() - start > timeoutNs) { return false; } if (++spins > MAX_SPINS) { LockSupport.parkNanos(1000); spins = 0; } } return true; }这个实现既避免了CPU空转，又能保证响应速度，在我们订单系统的库存扣减场景中，性能比ReentrantLock提升了约40%。