高频交易系统必须预分配内存池、禁用默认分配器与系统调用、使用RDTSC时间戳、lock-free日志、恰当memory_order、cache line对齐及CPU绑核。
内存分配必须绕开 malloc 和 new
高频交易系统中，每次动态内存分配都可能触发页表查找、锁竞争甚至系统调用，延迟从几十纳秒跳到微秒级。真实行情处理线程里出现一次 new Order()，就可能让整个 tick 处理路径超 500ns。
- 全程使用预分配的内存池（如
boost::pool或自研 ring buffer allocator），对象生命周期与会话/批次对齐 - 禁用 STL 容器的默认分配器；
std::vector必须传入自定义allocator，std::string改用std::string_view或固定长度char[32] - 避免 RAII 析构引发不可控延迟：不用
std::shared_ptr，析构逻辑手动管理，或统一在 batch 结束后批量清理
避免系统调用和内核态切换
任何 read()、write()、clock_gettime(CLOCK_MONOTONIC)、甚至 getpid() 都可能带来 100–500ns 的 syscall 开销，且受调度器干扰。L3 缓存未命中 + TLB miss + 上下文切换，延迟直接上微秒。
- 用
AF_XDP或DPDK绕过协议栈收发行情；UDP 报文直接从用户态网卡队列取，不进 socket buffer - 时间戳全部用
RDTSC（配合__rdtscp()防乱序）+ 启动时校准偏移，禁用所有gettimeofday类调用 - 日志不写磁盘、不 printf；用 lock-free ring buffer 存二进制 trace，离线 dump 分析
std::atomic 的 memory_order 选错会拖慢 3–10 倍
在 order book 更新、price level 同步等场景，盲目用 memory_order_seq_cst 会强制全核 fence，吞掉大量流水线收益。实测 x86 下 seq_cst store 比 relaxed 慢 7x，比 release 慢 4x。
- 仅当跨线程强顺序依赖时才用
seq_cst（例如确认订单已进入匹配引擎） - 价格快照、成交量累加等幂等操作，用
memory_order_relaxed即可 - 生产者-消费者边界（如 ring buffer tail 更新），用
memory_order_acquire/memory_order_release配对，避免 full barrier - 永远不要对
std::atomic_flag以外的类型用默认构造 —— 它隐式是seq_cst
CPU 绑核与 cache line 对齐不是可选项
一个未对齐的 struct Order 跨 cache line 存储，会让单次读取触发两次 L1d 访问；若又和隔壁线程的热数据共享同一 line，就会产生 false sharing —— 实测使订单解析吞吐下降 40%。
立即学习“C++免费学习笔记（深入）”；
- 关键结构体强制
alignas(64)，字段按大小降序排列（double,int64_t,int32_t, …），填空用char pad[...] - 每个核心独占一个物理 CPU（
taskset -c 2,3 ./trader），禁用 hyperthreading（BIOS 关闭，或只绑偶数核） - 中断亲和性重定向：把网卡 IRQ 绑到非交易线程的核（如 core 0），避免打断低延迟路径
- 编译加
-march=native -O3 -flto -fno-stack-protector -fno-exceptions，函数内联阈值调高（-finline-limit=1000）
struct alignas(64) Order {
uint64_t id;
int64_t price; // 8
int32_t qty; // 4
char side; // 1
char pad[27]; // to 64
};
真正卡住 HFT 性能的，往往不是算法复杂度，而是 cache line 边界是否对齐、RDTSC 校准是否覆盖了 TSC 不稳期、ring buffer 的 head/tail 是否落在同一 cache line —— 这些细节不压测根本看不出，一上线就成瓶颈。 
