超线程对低延迟开发的影响：为何需禁用Hyperthreading？

我们始终在关键路径上避免（相对）较慢的语言特性，如异常、内存分配和虚函数调用。I/O在单独线程中执行，并通过消息队列触发。超线程已禁用。我们提前准备尽可能多的数据，以减少关键路径上需要读取的缓存行数。

你疑惑为何超线程在此场景中是劣势，且一直认为“现代CPU开启超线程几乎不会变慢，因为操作系统的工作负载调度能力相当出色。”

核心原因：低延迟场景对资源独占性的极致要求 #

低延迟开发的核心目标是消除所有不确定的性能波动，超线程的设计逻辑和这个目标天生冲突，具体原因如下：

• 共享硬件资源的竞争：超线程让一个物理核心同时运行两个逻辑线程，二者会共享L1/L2缓存、执行单元、寄存器文件等核心硬件资源。低延迟关键路径上的线程需要独占这些资源来保证指令执行的连续性和确定性，一旦另一个逻辑线程抢占资源，就会导致缓存命中率下降、指令流水线停顿，引入不可预测的延迟波动——哪怕操作系统调度做得再好，也没法完全避免这种硬件层面的资源冲突。

• 调度带来的不确定性开销：低延迟场景的关键线程通常会绑定到特定物理核心运行（核心绑定），以此避免上下文切换和跨核心调度的开销。如果开启超线程，操作系统可能会把其他非关键线程调度到同一个物理核心的另一个逻辑线程上，哪怕这些线程占用资源不多，也可能干扰关键线程的执行节奏，比如突然触发缓存失效、抢占执行单元，导致关键路径的延迟突然飙升，这在微秒级甚至纳秒级要求的低延迟场景里完全无法接受。

• 预缓存策略的失效风险：帖子里提到会提前准备数据来减少关键路径的缓存读取量，本质是让关键数据常驻L1/L2缓存。但超线程的另一个逻辑线程可能读取无关数据，把关键数据挤出缓存，导致关键路径执行时不得不重新从内存加载，直接破坏了提前优化的效果，引入额外的内存访问延迟。

对通用认知的补充 #

“现代CPU开启超线程几乎不会变慢”的结论是针对通用计算场景的，比如日常办公、多任务处理、服务器多用户请求等，这些场景下线程间资源冲突概率低，超线程能提升整体吞吐量。但低延迟场景追求的不是吞吐量，而是单个关键任务的极致确定性和最低延迟，所以超线程的优势完全发挥不出来，反而会成为性能波动的来源。

内容的提问来源于stack exchange，提问作者user22691690