内存模型基础：CPU缓存层级、缓存行与伪共享、内存对齐、局部性原理
好，咱们开始聊内存模型。说实话，很多做量化交易的朋友，一开始都盯着算法、策略、回测框架，觉得这些才是核心。但真到了实盘环境，你会发现——内存访问模式才是那个决定你系统能不能跑进微秒级的隐形杀手。
我个人习惯把内存模型比作一个「仓库-货架-桌面」的体系。CPU核心就是你的工位，L1缓存是桌面上的工具盒，L2是旁边的文件柜，L3是走廊尽头的共享储物间，而主存嘛……就是楼下那个大仓库。你想想看，从桌面上拿个螺丝刀，跟跑到楼下仓库翻箱倒柜，时间能一样吗？
CPU缓存层级：为什么你的代码跑得慢？
先看一组数字，我当年第一次看到时也挺震撼的：
| 存储层级 | 典型延迟 | 大小 | 关联性 |
|---|---|---|---|
| L1 Cache | ~1ns (3-4 cycles) | 32KB - 64KB | 每个核心私有 |
| L2 Cache | ~4ns (10-12 cycles) | 256KB - 512KB | 每个核心私有 |
| L3 Cache | ~12ns (30-40 cycles) | 8MB - 32MB | 所有核心共享 |
| 主存 (DRAM) | ~60ns (200+ cycles) | GB级别 | 全局共享 |
嗯，这里要注意：一次主存访问的时间，够L1缓存执行200次操作。所以你的订单簿如果频繁触发主存访问，性能直接崩盘。
我在项目中遇到过最典型的场景：一个订单簿的深度快照，数据量其实不大，也就几百KB。但因为结构体设计不合理，每次更新都导致缓存行被反复刷掉。结果呢？一个简单的价格查询，硬生生从纳秒级拖到了微秒级。
缓存行与伪共享：看不见的锁
缓存行是CPU从主存读取数据的最小单位，通常是64字节。什么意思呢？就算你只想读一个4字节的int，CPU也会把相邻的60字节一起拉进来。
这本身是好事——空间局部性嘛。但问题出在多线程场景下。
伪共享（False Sharing），说白了就是：两个线程各自操作不同的变量，但这两个变量恰好落在同一个缓存行里。结果呢？每次线程A修改自己的变量，线程B的缓存行就失效了，得重新从主存加载。明明没有共享数据，却产生了共享冲突的开销。
我曾经在优化一个订单簿的「买一卖一」更新逻辑时，就踩过这个坑。两个线程分别更新买一价和卖一价，数据完全不重叠。但性能就是上不去，CPU利用率虚高。后来用perf一看，L1缓存缺失率爆表。嗯，典型的伪共享。
怎么解决？C++17提供了std::hardware_destructive_interference_size，可以获取当前平台的缓存行大小。但更直接的做法是手动padding：
// 避免伪共享的典型做法
struct alignas(64) HotData {
int64_t bid_price; // 线程A更新
char padding1[56]; // 填充到64字节
int64_t ask_price; // 线程B更新
char padding2[56]; // 填充到64字节
};内存对齐：编译器不会告诉你的秘密
内存对齐，说白了就是数据在内存中的摆放规则。CPU读取对齐的数据，一次内存访问就够了。不对齐的话，可能得读两次，再拼起来。
举个例子：
// 不对齐的结构体
struct Order {
char type; // 1字节
int64_t id; // 8字节
double price; // 8字节
int32_t volume; // 4字节
};
// 实际大小：1 + 7(填充) + 8 + 8 + 4 + 4(填充) = 32字节
// 对齐后的结构体
struct alignas(64) OrderAligned {
int64_t id; // 8字节
double price; // 8字节
int32_t volume; // 4字节
char type; // 1字节
char padding[3]; // 填充到16字节对齐
};
// 实际大小：8 + 8 + 4 + 1 + 3 = 24字节你看，只是调整了成员顺序，就省了8字节。在订单簿里，如果有一百万个订单，这就是8MB的内存节省。而且访问速度更快——因为CPU不需要做额外的对齐处理。
我个人习惯在定义订单簿数据结构时，按成员大小从大到小排列。这样既能保证对齐，又能减少padding浪费。
局部性原理：让数据「粘」在一起
局部性原理分两种：时间局部性和空间局部性。
- 时间局部性： 刚访问过的数据，很可能马上再访问一次。比如订单簿的买一价，每次行情更新都要读。
- 空间局部性： 刚访问过的数据附近的数据，很可能接下来要访问。比如遍历深度列表时，相邻的价格档位。
我在设计订单簿时，会刻意把「热点数据」紧凑排列。比如把买一、卖一、最新成交价放在同一个缓存行里。这样一次缓存行加载，就能拿到三个关键数据。
你想想看，如果你的订单簿用链表或者树结构存储深度数据，每次价格变动都要在内存里跳来跳去。CPU的预取器根本猜不到你下一步要访问哪里。但如果你用数组+游标的方式，数据是连续排列的，预取器就能提前把数据拉到缓存里。
一张图总结本章核心
下面这张图，是我自己画的内存模型与订单簿设计的对应关系。你可以看到，从CPU核心到主存，每一层都有对应的优化策略：
这张图想表达的核心思想很简单：你的订单簿数据，应该按照访问频率分层存放。最热的数据（买一卖一）要能塞进L1，活跃的深度数据要能塞进L2，完整的快照可以放在L3。如果连L3都放不下……嗯，那你得考虑数据分片或者压缩了。
好了，内存模型的基础就聊到这儿。记住一句话：在量化系统里，内存访问模式决定了你的延迟天花板。下一章我们会深入订单簿的具体数据结构设计，看看怎么把这些原则落地到代码里。