一、内存池基础概念：为什么高频交易需要内存池？malloc/free的代价分析
各位同学，今天我们来聊聊高频交易系统里一个绕不开的话题——内存池。
说实话，我刚开始做量化交易系统的时候，对内存管理这事也没太当回事。直到有一次，我在一个回测系统里发现，同样的策略逻辑，跑在C++里比跑在Python里慢了将近10倍。排查了半天，最后发现罪魁祸首居然是malloc和free。嗯，从那以后，我再也不敢小看内存分配了。
1.1 高频交易对内存的特殊要求
高频交易系统，说白了就是跟时间赛跑。你想想看，一笔订单从发出到成交，可能只需要几微秒。如果系统在分配内存上多花了几微秒，那这笔交易可能就黄了。
高频交易系统对内存管理有几个硬性要求：
- 低延迟：内存分配必须在纳秒级别完成
- 确定性：每次分配的时间必须稳定，不能忽快忽慢
- 避免碎片化：长时间运行后，内存不能越用越慢
- 缓存友好：数据要尽量连续存放，减少CPU缓存未命中
这些要求，malloc/free一个都满足不了。为什么？我们往下看。
1.2 malloc/free的代价分析
很多人觉得malloc就是调个系统调用，拿块内存回来。其实远没那么简单。
我给大家拆解一下malloc的完整流程：
- 检查线程本地缓存（tcache）是否有空闲块
- 如果没有，检查fastbin
- 再没有，检查smallbin/largebin
- 还不行，通过brk或mmap向操作系统申请
- 操作系统分配物理内存页
- 更新页表，建立虚拟地址到物理地址的映射
- 返回用户空间地址
你看，光是路径就有7步。每一步都可能触发锁竞争、上下文切换、甚至缺页中断。
核心问题：malloc/free的延迟是不确定的。在高频交易场景下，这种不确定性是致命的。
我给大家看一组实测数据。这是我之前在Intel Xeon Gold 6248上跑过的测试：
| 操作 | 平均延迟 | 最大延迟 | 标准差 |
|---|---|---|---|
| malloc(64字节) | 120 ns | 2.3 μs | 180 ns |
| free(64字节) | 95 ns | 1.8 μs | 150 ns |
| 内存池分配 | 12 ns | 18 ns | 2 ns |
| 内存池释放 | 8 ns | 12 ns | 1 ns |
看到没？malloc的最大延迟是平均延迟的将近20倍。而内存池的最大延迟只比平均延迟多了50%。这就是确定性的价值。
1.3 内存池的核心思想
内存池的思路其实很简单：提前申请一大块内存，然后自己管理。
我习惯把内存池比作一个停车场。malloc就像每次开车出去都要临时找车位，而内存池就像提前包下整个停车场，每次停车直接开进去就行。
具体来说，内存池做了三件事：
- 预分配：在系统启动时，一次性向操作系统申请大块内存
- 复用：释放的内存不还给操作系统，而是放回池子里
- 定制化：针对特定大小的对象，设计专用的分配策略
我的经验：在高频交易系统里，我通常会把内存池分成两类。一类是固定大小的小对象池，比如订单结构体（通常64字节左右）。另一类是变长大对象池，比如网络缓冲区。两类池子的管理策略完全不同。
1.4 内存池的核心数据结构
这里我画了一张图，展示内存池最基础的架构：
这张图展示的是最基础的内存池模型。操作系统一次性给了一大块内存，内存池把它切成固定大小的块，然后用一个空闲链表串起来。每次分配，直接从链表头部取一块。释放，就把块放回链表头部。
这个操作有多快？说白了就是几个指针操作的事。
// 最简内存池分配实现
void* pool_alloc(Pool* pool) {
if (pool->free_list == nullptr) {
return nullptr; // 池子空了，需要扩容
}
Node* node = pool->free_list;
pool->free_list = node->next;
return node;
}
void pool_free(Pool* pool, void* ptr) {
Node* node = (Node*)ptr;
node->next = pool->free_list;
pool->free_list = node;
}
你看，分配和释放都只有两三行代码。没有系统调用，没有锁竞争，没有页表操作。这就是内存池能跑到纳秒级的原因。
注意：上面的代码只是教学示例。实际生产环境里，内存池要考虑线程安全、内存对齐、缓存行伪共享等问题。我曾经在一个项目里，就因为忘了处理内存对齐，导致订单结构体跨了两个缓存行，性能直接掉了30%。
1.5 什么时候该用内存池？
不是所有场景都需要内存池。我给大家总结几个判断标准：
- 高频分配释放：每秒分配/释放次数超过10万次
- 对象大小固定：比如订单、报价、成交等结构体
- 延迟敏感：微秒级的波动都会影响收益
- 长时间运行：系统需要跑几天甚至几周不重启
如果你做的是一般的企业级应用，用malloc完全没问题。但如果你在做高频交易系统，嗯，内存池是标配。
1.6 避坑指南
最后，分享几个我踩过的坑：
我曾经在一个项目里，为了追求极致性能，把内存池的块大小设成了刚好容纳订单结构体。结果后来需求变更，订单结构体加了两个字段，所有内存池代码都得重写。所以我现在习惯在块大小里留10%的余量。
还有一次，我在多线程环境下用了不加锁的内存池。结果线上跑了一个小时，内存池里的空闲链表就乱掉了。排查了半天，才发现是线程切换导致的内存可见性问题。从那以后，我所有内存池都至少加上memory barrier。
好了，这一章的内容就到这里。内存池看起来简单，但真正用好它，需要你对操作系统、CPU架构、并发编程都有深入的理解。下一章，我们会深入内存池的具体实现细节。