第3章基础数据类型与性能

基础数据类型与性能：内存布局、缓存行对齐与 False Sharing 的实战

各位同学，今天我们来聊一个非常“接地气”的话题——基础数据类型在内存里到底是怎么躺着的？

你可能觉得这有什么好讲的？int 就是 4 个字节，long 就是 8 个字节，背下来不就完了？

嗯，理论上是这样。但我在高频交易系统里踩过的坑告诉我：内存布局的细节，直接决定了你的策略能不能跑在微秒级别。

一、基本类型的内存布局：比你想象的更“讲究”

先看一个最简单的例子：

struct Order {
    char    status;    // 1 字节
    int     price;     // 4 字节
    short   quantity;  // 2 字节
};

你猜这个结构体占多少内存？

1 + 4 + 2 = 7 字节？

错。在我的机器上，sizeof(Order) 返回的是 12 字节。

为什么会这样？因为编译器会做内存对齐。

核心规则：每个成员的起始地址必须是其自身大小的整数倍。整个结构体的大小必须是最大成员大小的整数倍。

拿上面的 Order 来说：

status 占 1 字节，地址 0
price 是 int，需要 4 字节对齐，所以从地址 4 开始，中间空出 3 个字节（padding）
quantity 是 short，2 字节对齐，从地址 8 开始
最后整个结构体需要对齐到 4 字节（最大成员 int），所以末尾再补 2 个字节

总大小：1 + 3(padding) + 4 + 2 + 2(padding) = 12 字节。

我的经验：在写交易报文解析时，我习惯把成员按大小从大到小排列。比如 int、short、char 这样排，能减少 padding，节省缓存行空间。别小看这 4 个字节，在百万级订单流里，缓存命中率差 5% 就是天壤之别。

二、缓存行对齐：为什么你的程序跑不快？

现代 CPU 不是按字节从内存读数据的。它一次读 64 字节，这就是一个缓存行（Cache Line）。

你想想看，如果你的结构体横跨了两个缓存行，CPU 就得读两次内存。在高频交易里，这多出来的一次内存访问，可能就是几十纳秒的延迟。

怎么解决？用 alignas。

struct alignas(64) AlignedOrder {
    int     price;
    int     volume;
    char    side;
};

这样，每个 AlignedOrder 对象都从 64 字节对齐的地址开始，并且整个结构体大小也是 64 的倍数。它永远不会跨缓存行。

注意：alignas 会让结构体变大。比如上面这个例子，原本可能 12 字节，对齐到 64 后，实际占用 64 字节。这是用空间换时间。我个人只在热路径（hot path）上使用，比如订单簿的顶层节点。

三、False Sharing：多线程性能的隐形杀手

这是我最想强调的一点。我曾经在一个做市商系统里，发现 8 个线程跑起来，性能还不如 4 个线程。查了三天，最后发现是 False Sharing 在作祟。

什么叫 False Sharing？

两个线程各自修改不同的变量，但这两个变量恰好在同一个缓存行里。CPU 为了保证缓存一致性，会让这两个线程的缓存行不断失效、重载。明明没有共享数据，却产生了共享的代价。

看代码：

struct Counter {
    int64_t a;  // 线程1 只修改 a
    int64_t b;  // 线程2 只修改 b
};

a 和 b 很可能在同一个缓存行里。线程 1 改 a，线程 2 的缓存行失效；线程 2 改 b，线程 1 的缓存行失效。来回折腾，性能直接腰斩。

解决方案：用 alignas 把它们分开。

struct alignas(64) Counter {
    int64_t a;
    char padding[56];  // 填充到 64 字节
    int64_t b;
    char padding2[56];
};

或者更优雅的方式，用 C++17 的 std::hardware_destructive_interference_size：

struct Counter {
    alignas(std::hardware_destructive_interference_size) int64_t a;
    alignas(std::hardware_destructive_interference_size) int64_t b;
};

避坑指南：我曾经在重构一个老系统时，把两个频繁更新的指标放在了一个结构体里。上线后延迟从 5 微秒飙到了 20 微秒。后来用 perf 工具一看，L1 缓存 miss 率从 2% 升到了 35%。加上 padding 后，一切恢复正常。所以，多线程下，凡是被不同线程频繁写的变量，一定要隔离到不同缓存行。

四、知识体系图：一张图看懂内存与性能

下面我用一张 SVG 图来总结本章的核心逻辑：

五、实战建议：写代码时的检查清单

最后，我总结几个我在代码审查时一定会检查的点：

热路径上的结构体：检查 sizeof，确认没有意外 padding。用 static_assert 固定大小。
多线程写变量：不同线程写的变量，必须隔离到不同缓存行。用 alignas(64) 或标准库工具。
读多写少的场景：不用过度对齐。比如配置参数，读一次后基本不变，对齐反而浪费缓存。
性能测试：任何对齐优化后，一定要用 perf 或类似工具看 L1/L2 缓存 miss 率。数据说话。

一个小技巧：我习惯在结构体定义后面加一行注释，标明预期大小和实际大小。比如：

// sizeof(Order) = 12, 预期 12, OK
struct Order { ... };

这样下次改代码时，一眼就能发现是否引入了额外的 padding。

好了，关于基础数据类型与性能，我们就聊到这里。记住：内存布局不是编译器的私事，而是你作为量化交易系统工程师的必修课。

📚 课程目录

基础数据类型与性能：内存布局、缓存行对齐与 False Sharing 的实战

一、基本类型的内存布局：比你想象的更“讲究”

二、缓存行对齐：为什么你的程序跑不快？

三、False Sharing：多线程性能的隐形杀手

四、知识体系图：一张图看懂内存与性能

五、实战建议：写代码时的检查清单