CPU 缓存 高并发探索

一、为什么 CPU 缓存对高并发如此重要？

1.1 速度鸿沟：CPU vs 内存

• 现代 CPU 主频 ≈ 3--5 GHz → 每条指令执行时间 ≈ 0.2--0.3 纳秒
• 主存（DRAM）访问延迟 ≈ 100 纳秒
• 差距达 300 倍以上！

如果每次读写都去主存，CPU 就像超跑在堵车------99% 时间在等！

1.2 CPU 缓存层级（Cache Hierarchy）

为弥合速度鸿沟，现代 CPU 引入多级缓存：

层级	容量	延迟	所有权
L1	32--64 KB	~1 ns	每核私有
L2	256 KB -- 1 MB	~3--5 ns	每核私有
L3	几 MB -- 几十 MB	~10--20 ns	所有核共享

数据访问路径：寄存器 → L1 → L2 → L3 → 主存

1.3 缓存行（Cache Line）------最小操作单位

• CPU 不是以字节为单位加载数据，而是以 64 字节 （x86_64 架构）为单位，称为一个 缓存行（Cache Line）
• 即使你只读一个 long（8 字节），也会把包含它的整个 64 字节块加载进缓存

这个设计是后续所有高并发缓存问题的根源！

---

二、高并发下缓存引发的两大核心问题

问题 1：伪共享（False Sharing）------看不见的性能杀手

▶ 场景

多个线程分别修改 不同变量 ，但这些变量落在 同一个缓存行 中。

▶ 后果

• CPU 使用 MESI 协议 维护缓存一致性
• 任一线程修改该缓存行 → 其他 CPU 核心的副本被 标记为无效（Invalid）
• 下次读取时必须重新从内存或其他核心同步 → 大量 cache miss + 总线风暴
• 表现为：多核并行反而比单线程更慢！

▶ Java 示例：未优化的计数器

public class FalseSharingDemo {
    static class SharedCounter {
        volatile long counter1; // 可能与 counter2 在同一缓存行
        volatile long counter2;
    }

    public static void main(String[] args) throws InterruptedException {
        var shared = new SharedCounter();

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50_000_000; i++) shared.counter1++;
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50_000_000; i++) shared.counter2++;
        });

        long start = System.nanoTime();
        t1.start(); t2.start();
        t1.join(); t2.join();
        System.out.println("耗时: " + (System.nanoTime() - start) / 1_000_000 + " ms");
    }
}

在 4 核机器上运行，可能耗时 800ms+，而单线程只需 200ms！

▶ 解决方案：缓存行填充（Padding）

方法 1：手动填充（兼容性好）

static class PaddedCounter {
    volatile long p1, p2, p3, p4, p5, p6, p7; // 7 * 8 = 56 字节
    volatile long counter1;                    // 第 64 字节开始
    volatile long q1, q2, q3, q4, q5, q6, q7; // 填充到下一个缓存行
    volatile long counter2;                    // 独占新缓存行
}

方法 2：使用 @Contended（Java 8+，需 JVM 参数）

import jdk.internal.vm.annotation.Contended;

@Contended
static class Counter1 {
    volatile long value;
}

@Contended
static class Counter2 {
    volatile long value;
}

启动时加参数：-XX:-RestrictContended

✅ 效果：上述例子运行时间可从 800ms 降至 250ms，接近理论最优！
"JDK 的 LongAdder 正是通过 @Contended 注解每个 Cell 对象，避免多个线程更新不同计数单元时发生伪共享，从而在高并发下远超 AtomicLong。"

---

问题 2：缓存局部性缺失 ------ 让 CPU 白忙活

▶ 原理

CPU 缓存依赖两个局部性原则：

• 时间局部性：刚访问的数据很可能再次被访问（如循环变量）
• 空间局部性：访问某地址，其附近地址也可能被访问（如数组连续元素）

▶ 反面教材：LinkedList vs ArrayList

// 场景：遍历 100 万个 long
List<Long> list1 = new ArrayList<>();     // 内存连续
List<Long> list2 = new LinkedList<>();    // 节点分散在堆中

// 测试遍历性能
long sum = 0;
for (Long x : list1) sum += x; // 快！缓存命中率高
for (Long x : list2) sum += x; // 慢！每次都要 load 新内存页

在高并发批处理、网络包解析等场景，ArrayList/数组性能通常是 LinkedList 的 3--10 倍！

▶ 高性能框架的实践

• Disruptor：使用环形数组（RingBuffer）存储事件，保证生产者/消费者顺序访问，最大化缓存命中
• Netty：ByteBuf 使用池化 + 连续内存块，避免频繁 GC 和缓存失效

---

三、volatile 与缓存一致性协议（MESI）

3.1 volatile 如何保证可见性？

• 当线程写 volatile 变量时，CPU 会：
  1. 修改本地缓存行
  2. 通过 总线嗅探（Bus Snooping） 发送 Invalidate 消息
  3. 其他 CPU 核心收到后，将对应缓存行置为 Invalid
  4. 下次读取时强制从主存或其他核心重新加载

这就是 happens-before 规则的硬件基础！

3.2 高并发下的代价

• 频繁写 volatile → 频繁 Invalidate → 缓存一致性流量激增
• 在 32 核机器上，高频写 volatile 可能导致 总线饱和，吞吐下降 50%+

▶ 正确姿势：用 LongAdder 替代 AtomicLong

// 高并发计数场景
AtomicLong atomic = new AtomicLong();      // 所有线程竞争同一个缓存行
LongAdder adder = new LongAdder();         // 每个线程分配独立 Cell

// 多线程调用
atomic.incrementAndGet(); // CAS + volatile write → 高竞争
adder.increment();        // 无锁分片 → 无伪共享（Cell 用 @Contended）

JDK 8 引入 LongAdder 正是为了应对高并发计数的缓存瓶颈！

---

四、实战建议：写出缓存友好的高并发代码

原则	做法	示例
避免伪共享	独立高频字段隔离到不同缓存行	@Contended、手动 padding
提升局部性	使用数组/紧凑对象，顺序访问	Disruptor RingBuffer
减少 volatile 写	用不可变对象、分段累加	LongAdder、final 字段
控制对象大小	对象 ≤ 64 字节可放入单个缓存行	避免大 POJO 嵌套
线程亲和性	关键任务绑定固定线程（间接提升 L1/L2 复用）	使用专用线程池

---

五、总结：亮点提炼

🔹 核心观点 ：

"在高并发系统中，瓶颈往往不在算法，而在缓存 。

我们写的每一行 Java 代码，最终都在和 CPU 缓存博弈。"
🔹 技术亮点：

• 伪共享是"隐形性能杀手"，@Contended 是 JDK 提供的精准手术刀
• LongAdder 通过 分片 + 缓存行隔离，实现近线性扩展
• Disruptor 的极致性能，一半功劳归于 缓存友好设计
  🔹 延伸思考 ：

"未来随着 CXL、存算一体等新技术发展，缓存层级可能重构，但'局部性'和'一致性'的权衡，永远是并发系统的底层命题。"