当前位置：首页 > news >正文

CPU 缓存高并发探索

news 2025/11/14 6:15:29

一、为什么 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 复用）	使用专用线程池