3. 内存管理优化：内存池设计与实现

内存管理，说白了就是高频交易系统的命门。

我刚开始做量化系统那会儿，用的还是Java。GC一触发，整个交易链路就像被人掐了脖子——延迟直接飙到毫秒级。后来转到C++，以为万事大吉了，结果发现动态分配new/delete照样能把你的延迟打爆。

为什么会这样？因为操作系统分配内存这件事，本身就不确定。你调用malloc，它可能去内核态走一圈，可能触发缺页中断，可能还要做内存碎片整理。这些操作，随便一个都是微秒级的开销。在高频交易里，微秒就是一辈子。

3.1 内存池的核心思想

内存池的思路其实很简单：提前分配，重复使用。

你想想看，既然每次分配内存都要跟操作系统打交道，那不如一次多要点，自己管。就像开餐馆，你不会每次客人点菜都去菜市场现买，而是提前备好食材。

我个人习惯把内存池分成两类：

• 固定大小内存池：每个块大小一样，适合存储订单、行情快照等固定结构体
• 可变大小内存池：块大小不同，适合存储变长消息

在高频交易场景下，我几乎只用固定大小内存池。为什么？因为简单、快、没有碎片。

3.2 内存池的典型实现

下面这个实现，是我在多个低延迟项目中用过的模板。它基于无锁队列（lock-free queue）的思想，用原子操作管理空闲块链表。

// 固定大小内存池 - 无锁版本
template<typename T, size_t PoolSize = 1024>
class LockFreeMemoryPool {
private:
    // 内存块头部，用于构建空闲链表
    struct Block {
        Block* next;
        char data[sizeof(T)];
    };
    
    // 预分配的内存区域
    Block* pool;
    // 空闲链表头
    std::atomic<Block*> free_head;
    
public:
    LockFreeMemoryPool() {
        // 一次性分配大块内存
        pool = static_cast<Block*>(std::aligned_alloc(64, PoolSize * sizeof(Block)));
        
        // 构建空闲链表
        for (size_t i = 0; i < PoolSize - 1; ++i) {
            pool[i].next = &pool[i + 1];
        }
        pool[PoolSize - 1].next = nullptr;
        free_head.store(&pool[0], std::memory_order_release);
    }
    
    T* allocate() {
        Block* block = free_head.load(std::memory_order_acquire);
        while (block != nullptr) {
            // CAS操作：尝试从空闲链表头部取出一个块
            if (free_head.compare_exchange_weak(block, block->next,
                std::memory_order_acq_rel)) {
                return reinterpret_cast<T*>(block->data);
            }
        }
        return nullptr; // 池已耗尽
    }
    
    void deallocate(T* ptr) {
        Block* block = reinterpret_cast<Block*>(
            reinterpret_cast<char*>(ptr) - offsetof(Block, data));
        block->next = free_head.load(std::memory_order_acquire);
        while (!free_head.compare_exchange_weak(block->next, block,
            std::memory_order_acq_rel)) {
            // 重试直到成功
        }
    }
    
    ~LockFreeMemoryPool() {
        std::free(pool);
    }
};

3.3 大页内存（Huge Pages）配置与效果

内存池解决了动态分配的问题，但还有一个隐藏的坑——TLB（页表缓存）缺失。

标准内存页是4KB大小。如果你的工作集很大（比如几十GB的行情数据），TLB会频繁缺失，每次都要去查页表，这个开销在纳秒级，但累积起来就很可观。

大页内存（Huge Pages）就是把页大小从4KB提升到2MB甚至1GB。这样一来，同样的TLB条目数，能覆盖的内存范围大了512倍甚至25万倍。

我做过一个测试：同样的行情回放程序，用4KB页时TLB缺失率是3.2%，换成2MB大页后降到0.01%以下。延迟从平均1.2微秒降到了0.8微秒。

3.4 配置大页内存

在Linux系统上，配置大页内存分两步：

1. 预留大页：在系统启动时或运行时预留
2. 挂载hugetlbfs：让应用程序可以使用大页

运行时预留大页的命令：

# 预留1024个2MB大页（总共2GB）
echo 1024 > /proc/sys/vm/nr_hugepages

# 查看是否成功
cat /proc/meminfo | grep HugePages
# 输出示例：
# HugePages_Total:    1024
# HugePages_Free:     1024
# HugePages_Rsvd:        0
# HugePages_Surp:        0

挂载hugetlbfs：

# 创建挂载点
mkdir -p /mnt/hugepages

# 挂载hugetlbfs
mount -t hugetlbfs hugetlbfs /mnt/hugepages

# 设置权限（让非root用户也能用）
chmod 777 /mnt/hugepages

在代码中使用大页：

#include <sys/mman.h>
#include <fcntl.h>

// 通过hugetlbfs文件系统分配大页内存
int fd = open("/mnt/hugepages/data", O_CREAT | O_RDWR, 0755);
if (fd < 0) {
    // 处理错误
}

// 映射2MB大页
void* addr = mmap(NULL, 2 * 1024 * 1024, 
                  PROT_READ | PROT_WRITE, 
                  MAP_SHARED | MAP_HUGETLB, 
                  fd, 0);

if (addr == MAP_FAILED) {
    perror("mmap failed");
    close(fd);
    return;
}

// 使用内存...
// 使用完后释放
munmap(addr, 2 * 1024 * 1024);
close(fd);

3.5 内存池 + 大页内存的协同效果

把内存池分配在大页内存上，效果是1+1>2的。

内存池消除了动态分配的开销，大页内存降低了TLB缺失。两者结合，你的数据管道在内存访问这一块，基本就没什么瓶颈了。

我习惯的做法是：

• 用大页内存作为底层存储
• 在上面构建固定大小的内存池
• 内存池内部用无锁队列管理空闲块
• 每个线程绑定一个独立的内存池（避免伪共享）

下面这张图展示了整个架构：

3.6 避坑总结

最后，把我这些年踩过的坑列一下：

• 不要用std::allocator：STL的分配器虽然方便，但它的设计目标是通用性，不是低延迟。我见过有人用std::allocator包装内存池，结果因为内部锁竞争，性能还不如直接用malloc。
• 注意伪共享：内存池的每个块最好按缓存行对齐（64字节）。我踩过这个坑——两个线程各自分配内存，结果两个对象恰好在同一个缓存行上，性能直接腰斩。
• 大页不是越大越好：1GB大页虽然覆盖范围大，但分配粒度太粗，容易造成浪费。我一般用2MB大页，除非你的单个数据结构超过1GB。
• 监控内存池水位：内存池耗尽时，allocate返回nullptr。我习惯在池中加一个水位线，当使用量超过80%时报警，提前扩容。

嗯，内存管理这块，说白了就是「提前规划，避免运行时的不确定性」。你把这些做好了，数据管道的延迟基本就稳了。

---