第4章：内存与缓存优化——让数据访问快如闪电

做市商系统里，延迟就是金钱。我见过太多团队把精力花在算法优化上，却忽略了内存访问这个最大的瓶颈。说实话，一次缓存未命中的代价，可能比执行几十条指令还高。今天我们就来聊聊，怎么把内存和缓存这块硬骨头啃下来。

4.1 内存池设计——告别频繁的内存分配

做市商系统里，订单、报价、成交这些对象，每秒可能创建和销毁几百万次。如果每次都调用 malloc 或 new，系统性能会直接崩掉。为什么？因为内存分配器需要维护复杂的数据结构，还要处理多线程竞争。

我个人的习惯是，在系统启动时就预分配一大块内存，然后自己管理。这就是内存池的核心思想。

// 一个简单的内存池实现
template<typename T>
class MemoryPool {
private:
    char* pool;          // 预分配的内存块
    size_t block_size;   // 每个对象的大小
    size_t capacity;     // 最大对象数
    void* free_list;     // 空闲链表头
    
public:
    MemoryPool(size_t count) 
        : block_size(sizeof(T)), capacity(count) {
        // 一次性分配所有内存
        pool = (char*)aligned_alloc(64, block_size * count);
        
        // 初始化空闲链表
        free_list = pool;
        for (size_t i = 0; i < count - 1; ++i) {
            void* curr = pool + i * block_size;
            void* next = pool + (i + 1) * block_size;
            *(void**)curr = next;
        }
        *(void**)(pool + (count - 1) * block_size) = nullptr;
    }
    
    T* allocate() {
        if (!free_list) return nullptr;
        void* ptr = free_list;
        free_list = *(void**)ptr;
        return new (ptr) T();
    }
    
    void deallocate(T* ptr) {
        ptr->~T();
        *(void**)ptr = free_list;
        free_list = ptr;
    }
};

我在项目中遇到过一个问题：内存池的块大小如果设置不当，会导致严重的内部碎片。比如你分配了64字节的块，但实际对象只需要48字节，那16字节就浪费了。我的建议是，根据实际对象大小，向上对齐到缓存行大小（通常是64字节）。

4.2 对象复用——别让对象生生死死

你想想看，每次创建一个新对象，都要调用构造函数、分配内存、初始化成员变量。销毁时又要调用析构函数、释放内存。这些操作虽然单个看起来不慢，但架不住数量多啊。

对象复用的思路很简单：用完了别扔，洗干净再用。具体做法就是维护一个对象池，用的时候从池子里取，用完再还回去。

// 订单对象复用示例
class OrderRecycler {
private:
    std::vector<Order*> available;
    std::mutex mtx;
    
public:
    Order* acquire() {
        std::lock_guard<std::mutex> lock(mtx);
        if (available.empty()) {
            return new Order();  // 池子空了才创建新对象
        }
        Order* order = available.back();
        available.pop_back();
        order->reset();  // 重置状态，而不是重新构造
        return order;
    }
    
    void release(Order* order) {
        std::lock_guard<std::mutex> lock(mtx);
        available.push_back(order);
    }
};

这里有个坑要注意：重置对象时，一定要把所有成员变量都清干净。我曾经因为漏掉了一个标志位，导致旧数据被当成新数据使用，查了半天才找到原因。

4.3 避免GC——C++的优势要发挥出来

做市商系统为什么用C++而不是Java？一个很重要的原因就是GC。Java的垃圾回收器虽然越来越先进，但Stop-The-World暂停始终是个隐患。在高频交易场景下，哪怕暂停1毫秒，都可能导致错过行情或报价延迟。

C++没有GC，但如果你用智能指针不当，也会产生类似的问题。比如 shared_ptr 的引用计数操作是原子的，多线程下会有性能开销。我建议在性能关键路径上，尽量用原始指针配合内存池。

说白了，避免GC的核心就是：自己管理内存生命周期。用内存池分配，用对象池复用，用RAII管理资源。这样既没有GC暂停，也没有引用计数开销。

4.4 缓存行对齐——让数据待在CPU缓存里

现代CPU的缓存行通常是64字节。也就是说，CPU从内存读取数据时，一次读64字节。如果你的数据跨了两个缓存行，那就要读两次，性能直接减半。

我个人的做法是，把热数据（频繁访问的成员变量）放在结构体的开头，并且保证整个结构体大小是64字节的整数倍。

// 缓存行对齐示例
struct alignas(64) Order {
    int64_t order_id;      // 8字节
    int64_t price;         // 8字节
    int64_t quantity;      // 8字节
    int32_t side;          // 4字节
    int32_t status;        // 4字节
    // 填充到64字节
    char padding[32];
};

// 或者用编译器指令
struct __attribute__((aligned(64))) Order {
    // ... 成员变量
};

这里要注意，alignas(64) 只是告诉编译器按64字节对齐，但结构体内部成员可能还是会有填充。我建议手动计算一下大小，确保没有浪费。

4.5 伪共享——多线程性能的隐形杀手

伪共享（False Sharing）是个很隐蔽的问题。它发生在多个线程访问不同变量，但这些变量恰好在同一个缓存行里。CPU为了保证缓存一致性，会让这些缓存行在不同核心之间来回传递，导致性能急剧下降。

我记得有一次，系统在8核机器上跑，但性能只比单核好一点点。排查了半天，发现是两个线程频繁访问的两个计数器，被分配到了同一个缓存行里。

// 伪共享的例子
struct Counter {
    int64_t thread1_count;  // 线程1频繁访问
    int64_t thread2_count;  // 线程2频繁访问
    // 这两个变量很可能在同一个缓存行里！
};

// 解决方案：用填充隔离
struct alignas(64) Counter {
    int64_t thread1_count;
    char padding1[56];  // 填充到64字节
};

struct alignas(64) Counter2 {
    int64_t thread2_count;
    char padding2[56];  // 填充到64字节
};

4.6 实战建议——把这些技术组合起来

说了这么多，怎么在实际系统里用呢？我总结了几条经验：

1. 先分析，再优化。用perf或VTune看看哪些内存访问是热点，别盲目优化。
2. 内存池 + 对象复用 + 缓存行对齐，这三者要一起用。单独用任何一个，效果都有限。
3. 多线程场景下，优先解决伪共享。它的性能影响往往最大，而且最难发现。
4. 测试要覆盖极端情况。比如行情爆发时的内存压力，多线程竞争时的缓存行为。

最后说一句，内存优化是个持续的过程。系统上线后，随着业务变化，原来的优化可能就不适用了。定期做性能分析，保持对内存布局的敏感，这是每个做市商系统工程师的必修课。