SO_REUSEPORT 通过为每个线程创建独立 socket 并启用该选项，避免 accept 队列争用，提升并发吞吐；需 Linux 3.9+，且必须在 socket() 后立即 setsockopt；配合 epoll_wait 轮询、EPOLLET、sendmmsg 批量发包、AF_PACKET 零拷贝收包及关闭网卡 offload，可显著降低延迟并提升性能。
用 SO_REUSEPORT 避免 accept 队列争用
多线程监听同一个端口时，内核默认把所有新连接塞进一个全局 accept 队列，线程抢着 accept() 会引发锁竞争和缓存颠簸——实测在 10G 网卡 + 40 核机器上，单队列吞吐卡在 8–12 万连接/秒，启用 SO_REUSEPORT 后轻松翻倍。
关键不是“能不能用”，而是“必须每个 socket 单独 setsockopt”：
-
socket()后立即调用setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt))，不能等bind()之后 - 多个线程需各自创建独立
socket、bind到同一地址，再listen；共用一个 fd 再 fork 不行 - Linux 3.9+ 才完整支持，旧内核（如 CentOS 7 默认 3.10）可用，但需确认
/proc/sys/net/core/somaxconn≥ 65535
epoll_wait 超时设为 0 还是 -1？
设 -1（永久阻塞）看似省电，但在 HFT 场景下会让事件处理延迟不可控：网卡中断到用户态回调之间，可能被调度器插进一个 50μs 的其他任务。实测将 epoll_wait 超时设为 0（轮询），配合 busy_poll 内核参数，端到端 P99 延迟下降 18–22μs。
但代价明显：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- CPU 使用率从 12% 拉到 35%，需绑定独占 CPU 核，禁用
intel_idle和cpufreq - 必须搭配
EPOLLET边沿触发，否则重复通知导致 busy loop -
epoll_wait返回后要立刻处理完所有就绪 fd，不能中途 sleep 或阻塞 I/O
发包不走 sendto，改用 sendmmsg 批量提交
单次 sendto 触发一次 syscall + 上下文切换，高频报价场景下每秒几万次调用，光上下文切换就吃掉 3–5μs/次。用 sendmmsg 一次提交最多 1024 个 msghdr，实测在 25Gbps 网卡上，吞吐提升 2.1 倍，P50 延迟压到 8.3μs。
注意三个硬约束：
- 所有消息必须发往同一目标地址（
sockaddr相同），跨 IP 必须分组调用 - 每个
msghdr的msg_iov总长度不能超net.core.wmem_max（通常 212992 字节） - 内核 3.0+ 才支持，且需确保
CONFIG_NETFILTER_XT_TARGET_TPROXY_SOCKET未启用（某些发行版默认开，会干扰sendmmsg路径）
UDP 收包避免 recvfrom 拷贝：用 recvmmsg + AF_PACKET 零拷贝
标准 recvfrom 每次都从内核 skb 拷贝到用户 buffer，对 10K+/秒 的行情 tick，仅内存带宽就占满 PCIe 3.0 x4 的 30%。真低延迟必须绕过协议栈：
- 用
AF_PACKET+TPACKET_V3直接 mmap 网卡 ring buffer，收包零拷贝，但需自己解析 IP/UDP 头 -
recvmmsg批量收包比循环调用recvfrom少 70% 的 syscall 开销，且能复用同一 buffer pool 减少 malloc 压力 - 必须关闭 NIC offload：
ethtool -K eth0 gso off tso off gro off lro off，否则AF_PACKET可能收到分片或聚合包
最麻烦的其实是时序校准——AF_PACKET 时间戳来自网卡硬件，而业务逻辑依赖系统时钟，两者偏差可能达 ±200ns，得用 PTP 或 GPSDO 对齐，这点容易被忽略。
