背景痛点：MESI 协议下的“隐形”写放大
第一次做高并发计数器时，我把AtomicLong当成万能药，结果 32 线程压测 QPS 只有 18 万，比单线程还低。用perf一看，大量 CPU 周期花在lock cmpxchg上，cache-miss 高达 30%。
根源是 MESI 协议：当多核同时修改同一缓存行，硬件必须串行化所有权转移。每次 CAS 成功前，其他核的对应缓存行被置为 Invalid，下一次又重新加载，形成“写放大”。如果计数器周边字段被误放在同一缓存行（False Sharing），本应是局部变量的写操作也会触发总线嗅探，延迟从 20 ns 飙到 200 ns 以上，QPS 直接腰斩。
技术对比：AtomicLong vs LongAdder vs StampedLock
下面给出 JMH 基准，场景是 1 亿次自增，线程数 1→64，测试机：Intel 8260，JDK 21。
@BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.SECONDS) @State(Scope.Group) @Threads(64) public class CasLatencyCompare { private final AtomicLong al = new AtomicLong(); private final LongAdder la = new LongAdder(); private final StampedLock sl = new StampedLock(); private long v; @Benchmark @Group("atomic") public void measureAtomic() { al.incrementAndGet(); } @Benchmark @Group("adder") public void measureAdder() { la.increment(); } @Benchmark @Group("stamped") public void measureStamped() { long stamp = sl.writeLock(); try { v++; } finally { sl.unlockWrite(stamp); } } }结果（ops/s，越高越好）：
| 线程数 | AtomicLong | LongAdder | StampedLock |
|---|---|---|---|
| 1 | 210 M | 190 M | 180 M |
| 8 | 35 M | 180 M | 40 M |
| 32 | 9 M | 170 M | 15 M |
| 64 | 5 M | 160 M | 8 M |
结论：竞争强度越高，LongAdder 通过“分段”降低 CAS 频率，延迟优势越明显；StampedLock 仍逃不过同一缓存行的串行化。
核心方案
1. 缓存行填充：@Contended 实战
@jdk.internal.vm.annotation.Contended // JDK 15+ 可用，开启 -XX:-RestrictContended @ThreadSafe public final class PaddedAtomicLong { private final AtomicLong value = new AtomicLong(0); // 隐式填充 56 byte，保证独占缓存行 }开启-XX:-RestrictContended后，perf 观察到 cache-miss 从 30% 降到 5%，32 线程 QPS 提升 2.3 倍。
2. 指数退避：降低失败重试的瞬时压力
@ThreadSafe public class BackoffCounter { private final AtomicLong counter = new AtomicLong(0); private static final int MIN_DELAY = 1; private static final int MAX_DELAY = 1024; public void increment() { int delay = MIN_DELAY; long old, neu; do { old = counter.get(); neu = old + 1; if (counter.compareAndSet(old, neu)) { return; } // 指数退避 int n = ThreadLocalRandom.current().nextInt(delay); LockSupport.parkNanos(n); delay = Math.min(delay << 1, MAX_DELAY); } while (true); } }在高冲突场景下，退避把总线风暴从 100 万次降到 15 万次，平均延迟下降 35%。
3. 批量提交：环形缓冲区解耦
@ThreadSafe public class BatchCounter { private static final int SIZE = 1 << 14; // 16k 槽位 private final AtomicLong head = new AtomicLong(0); private final AtomicLong tail = new AtomicLong(0); @GuardedBy("head") private final long[] ring = new long[SIZE]; public void add(long delta) { long t = tail.getAndIncrement(); ring[(int) (t & (SIZE - 1))] = delta; } public long drainToSum() { long h, t; do { h = head.get(); t = tail.get(); } while (!head.compareAndSet(h, t)); long sum = 0; for (long i = h; i < t; i++) { sum += ring[(int) (i & (SIZE - 1))]; } return sum; } }业务线程只写环形数组，无 CAS 竞争；后台单线程定时 drain，把 1 万次写合并成 1 次 CAS，延迟从 180 ns 降到 25 ns。
避坑指南
- 过度填充会浪费 L1 容量，反而降低命中率。建议只在“热”字段使用
@Contended，并配合-XX:ContendedPaddingWidth=128调优。 - NUMA 机器上，CAS 延迟与节点距离正相关。把线程绑在同一 node (
numactl --cpunodebind=0) 可让延迟再降 15%。 - 写倾斜：当业务用 CAS 做“余额扣减”，高并发下可能出现 ABA 导致透支。使用
AtomicStampedReference或加版本号字段，保证“值+版本”双检。
延伸思考
当上述手段仍无法满足 99.9th 延迟 < 100 µs 的 SLA 时，是否需要引入形式化验证（如 TLA+）来证明算法正确性，而非继续调优代码？欢迎分享你在生产环境转向形式化工具的经验与踩坑。
如果你也想把“低延迟”理念落到可运行的完整项目，不妨体验下从0打造个人豆包实时通话AI动手实验：里面同样涉及环形缓冲、指数退避等并发技巧，边写代码边验证，对理解本文的优化点非常有帮助。
