CPU 的瓶颈不只有算力：指令依赖、缓存访问、地址翻译、共享数据和调度，共同决定线程真正推进的速度。

核心、线程与整机平均值

逻辑 CPU 是操作系统调度的执行目标，不等于独立的物理核心；是否支持同时多线程取决于具体处理器。插槽、核心、硬件线程和 NUMA 节点分别表达封装、执行资源、调度资源和访问距离，不能彼此替换。

整机有很多核心，单线程热点仍只能沿其依赖链推进。一个业务线程持续运行而其他核心空闲时，平均 CPU 利用率可能很低。这个原创场景说明“整机不满”不能排除执行瓶颈；它不说明任意低利用率问题都是单线程限制。

指令运行需要三种条件

线程需要获得调度时间，需要相应执行资源，还需要指令和操作数可用。算法存在长依赖链时，后续工作不能任意提前。数据分散、分支难预测或需要等待共享状态时，名义主频并不能直接换算成业务吞吐。

执行模型可以理解成可重叠的工作窗口：独立任务可能并行推进，依赖当前结果的任务必须等待。它不是厂商流水线说明，也不预设鲲鹏或 x86 的具体微架构。

缓存行是共享与搬运的基本观察尺度

连续访问和指针追踪的工作量即使相同，地址依赖也不同。连续数据更容易形成局部性；每次必须先读一个指针才能知道下一地址的路径，潜在并行度较低。工作集超过某级缓存时，访问更低层存储的机会增加，但“超过容量”不是一个无条件的瞬时性能开关。

线程推进
  +-- 有执行时间？ --> 调度/配额
  +-- 输入已就绪？ --> 数据依赖/缓存/地址翻译
  +-- 共享状态允许？ --> 锁/原子操作/一致性通信
  +-- 后续工作独立？ --> 可重叠程度

图用于拆分假设，不代表工具能直接给出这些条件的全部答案。性能计数器含义与事件支持必须对应处理器、内核和工具版本。

真共享与伪共享

共同更新一个计数器是真共享，业务本身需要协调。两个线程更新不同变量，但变量落在同一缓存行，则可能出现伪共享。Linux 的 False Sharing 文档 描述了后一类问题。缓存行竞争解释的是通信成本，不能替代程序正确性分析。

原创场景：统计请求数的共享计数器由所有工作线程更新。增加线程后，每个线程计算量减少，但计数器协调变多。若改成分片统计，合并阶段和统计精度也会改变；“拆开变量就能线性扩展”并不是普遍结论。

缓存一致性不等于同步正确性

不同核心能通过一致性机制协调共享缓存行，并不意味着一组变量的更新自动形成事务。生产者写完载荷后公布“就绪”，消费者需要遵守语言与平台同步协议。普通读写、原子性和内存序分别解决不同问题，见 一致性与内存序。

从业务现象到可验证假设

高 CPU 时间而吞吐低，可能是算法、锁竞争或额外内核工作；低 CPU 时间而响应慢，可能是 I/O、配额、调度或外部依赖。热点位置表示观察到的执行集中，不自动表示错误所在。

可信描述需要记录线程维度、采样窗口、运行队列、配额以及业务完成率。资源限制语义可查 cgroup v2。跨节点问题继续看 NUMA，设备交互继续看 DMA。

服务器知识库 · 系统架构 · 数据路径 · 测试验收 · 工程参考

公开资料核对：2026-10-07。文档类型：Explanation。逻辑图、场景推演与报告模板为原创，不代表实测结果、厂商内部设计或公司制度；操作仅限获授权的目标和环境。