不能用 std::map 或 std::unordered_map 做订单簿索引，因其时间复杂度和内存访问模式无法满足微秒级响应：std::map 的 O(log n) 查找在 10⁵ 订单下常超 500ns；std::unordered_map 虽均摊 O(1)，但哈希冲突、rehash 和随机访存导致 P99 > 2μs。
为什么不能用 std::map 或 std::unordered_map 做订单簿索引
因为它们的平均/最坏时间复杂度不满足微秒级响应要求：std::map 是 O(log n) 红黑树，单次插入/查找在 10⁵ 订单量级下常超 500ns；std::unordered_map 虽均摊 O(1)，但哈希冲突、rehash 和内存随机访问会引入不可控抖动（实测 P99 > 2μs）。真实撮合引擎必须规避动态内存分配和指针跳转。
实操建议：
- 用
std::vector预分配订单池（如std::vector），所有订单生命周期内地址固定 - 价格档位用静态数组或环形缓冲区（如
PriceLevel[10000]），索引直接为 price × 100（整数化） - 每个
PriceLevel内部用双向链表头尾指针（Order*）而非 vector —— 插入/删除 O(1)，且避免移动内存 - 禁止在匹配循环中调用
new、malloc、std::make_shared，所有对象从预分配池中placement new构造
如何让限价单匹配逻辑跑进 300ns（不含 IO）
关键不是“写得快”，而是“别做多余的事”。标准撮合（按价格优先、时间优先）在 CPU 指令级有明确瓶颈：分支预测失败、缓存行失效、非对齐访存。
实操建议：
- 把买盘/卖盘分离为两个独立结构体，避免 if (side == BUY) 分支 —— 编译器可完全展开
- 订单队列头部指针用
__m128i对齐存储（16 字节对齐），确保Order*解引用不跨 cache line - 匹配循环中禁用异常、RTTI、虚函数；所有函数标记
[[gnu::always_inline]]，但仅对 ≤ 12 行的热路径函数启用 - 用
__builtin_expect显式提示编译器：撮合成功是常态（if (__builtin_expect(matched, 1))），失败路径放冷区 - 示例片段（简化）：
while (bid_price >= ask_price && !bid_queue.empty() && !ask_queue.empty()) { auto& bid = *bid_queue.front(); auto& ask = *ask_queue.front(); const uint32_t trade_qty = std::min(bid.qty, ask.qty); // ... 更新 qty、触发回调 if (bid.qty == 0) bid_queue.pop_front(); if (ask.qty == 0) ask_queue.pop_front(); }
如何安全处理订单取消与部分成交下的并发修改
锁（std::mutex）会直接杀死延迟 —— 单次 lock/unlock 在现代 CPU 上常 > 20ns，且引发 cache coherency traffic。无锁（lock-free）又极易出错，比如 ABA 问题导致订单丢失。
实操建议：
- 采用 per-price-level 分段锁：只对涉及的价格档加细粒度
std::atomic_flag（test-and-set），而非全局锁 - 取消订单不真的“删节点”，而是设
order.status = CANCELLED，并在匹配循环开头跳过该订单（避免链表重连开销） - 所有订单结构体中预留
std::atomic，每次修改前version fetch_add(1)，回调层通过版本号判断是否被覆盖 - 禁止跨线程共享同一
Order实例指针 —— 输入线程解析完订单后，用 ring buffer 推送到匹配线程，匹配线程独占处理
为什么 mmap + hugepage 是比 malloc 更稳的内存策略
普通 malloc 分配的页是 4KB，TLB miss 高频发生；而 2MB 大页（MAP_HUGETLB）使 TLB 覆盖范围扩大 512 倍，实测减少 70% 的 TLB miss。更重要的是：mmap 分配的内存不会被 swap —— 金融系统里 swap 是硬性红线。
实操建议：
- 启动时用
mmap(nullptr, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0)申请大页池 - 配合
memlockulimit 设置（ulimit -l unlimited），否则 mmap 大页会失败并 fallback 到普通页 - 订单池、价格档数组、日志缓冲区全部从该 mmap 区域中
operator new（重载全局 new 使用该地址） - 注意：需提前配置系统开启大页（
echo 2048 > /proc/sys/vm/nr_hugepages），否则运行时报ENOMEM
真正难的不是写出低延迟代码，而是让每行代码都清楚自己在哪个 cache line 里、会不会触发 page fault、有没有隐式内存屏障。这些细节不会报错，但会让 P99 延迟从 800ns 悄悄爬升到 12μs。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
