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