超线程为何无法提升Web Worker性能？navigator.hardwareConcurrency为何失准？

StackOverflow上多个回答都指出，Web Worker的最优使用数量等于机器的物理核心数，而非逻辑核心数。这和我的测试结果完全吻合：我的MacBook开启了超线程，系统显示4个物理核心、8个逻辑核心，但实际测试中，使用4个Web Worker时性能达到峰值，而非8个。

核心疑问 #

• 超线程的设计是让单个CPU核心在每个时钟周期并行执行两条指令，以此模拟两个核心的功能，那为什么额外的Web Worker线程无法借助超线程提升性能？
• JavaScript中的navigator.hardwareConcurrency属性通常返回逻辑核心数，但该属性的设计初衷是为开发者提供Web Worker的最优使用数量。MDN文档提到：

  逻辑处理器核心数可用于衡量无需上下文切换即可有效同时运行的线程数量。不过，浏览器可能会选择报告更少的逻辑核心数，以更准确地表示可同时运行的Workers数量。
  但实际情况是，JS开发者普遍认为Web Worker的最优数量和物理核心数更相关，navigator.hardwareConcurrency返回的数值有误导性，甚至有专门工具用于计算物理核心数来确定Worker的最优数量。

背后的深层原因 #

1. 超线程的实际工作逻辑限制 #

超线程并非真正的“双核心”，它只是在单个物理核心内共享执行资源（比如缓存、运算单元），同时处理两个线程的指令。但如果两个线程都是CPU密集型任务（Web Worker通常用于这类场景），它们会争抢同一物理核心的有限资源，导致实际并行效率远低于两个独立物理核心。此时开启超过物理核心数的Worker，反而会因为线程上下文切换、资源竞争带来额外开销，抵消超线程的微弱优势，甚至导致性能下降。

2. JavaScript引擎的线程调度特性 #

浏览器的JS引擎（比如V8）在调度Web Worker线程时，会依赖操作系统的线程调度器。但操作系统对超线程的调度优化，更多是针对不同类型的任务（比如一个线程等待IO，另一个线程利用空闲资源）。而Web Worker执行的大多是同类型的CPU密集型任务，这种情况下超线程的资源共享优势无法发挥，物理核心的数量才是真正的并行能力上限。

3. navigator.hardwareConcurrency的设计考量 #

这个属性返回逻辑核心数，主要是因为：

• 操作系统对外暴露的通常是逻辑核心数，浏览器获取硬件信息的接口依赖系统提供的数据；
• 超线程的实际收益因任务类型差异极大，浏览器无法精准判断开发者的Worker任务类型，所以只能返回系统提供的逻辑核心数作为参考，而非直接给出物理核心数；
• 部分浏览器会根据自身调度策略调整返回值，但并没有统一标准来匹配物理核心数，导致该属性对CPU密集型Worker场景的参考价值有限。

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