线程状态高频迁移本身不直接耗cpu，但暴露锁竞争引发的调度抖动与缓存震荡，导致总线因频繁锁请求、缓存行无效化和mesi协议开销而过载；根源是锁争抢，而非状态切换。
这个问题的核心在于：线程状态迁移本身不直接消耗大量 cpu，但高频迁移背后往往暴露了严重的同步瓶颈——尤其是锁竞争引发的“调度抖动”与“缓存震荡”，最终让 cpu 总线（特别是前端总线或互连总线）陷入频繁的锁请求、缓存行无效化和一致性协议开销中，形成事实上的“总线锁竞争过载”。
线程状态迁移是表象，锁争抢才是根源
当多个线程反复在 RUNNABLE ↔ BLOCKED/WAITING 之间切换（例如争抢同一把 synchronized 锁或 pthread_mutex_t），操作系统必须频繁执行以下动作：
- 保存/恢复寄存器上下文（涉及 TLB、cache line 刷新）
- 更新调度队列与线程控制块（TCB），触发内核数据结构竞争
- 调用 futex 系统调用进入内核态，引发用户态/内核态切换开销
- 唤醒等待线程时需广播 IPI（Inter-Processor Interrupt），跨核通知带来总线流量激增
总线锁竞争过载的真实发生路径
现代多核 CPU 中，锁操作不只是软件逻辑，它会驱动硬件级一致性协议（如 MESI/MOESI）。一次简单锁获取可能触发：
- 多个核心对同一缓存行（含锁变量）发起 Exclusive 请求 → 引发该缓存行在各核间反复失效（Invalidation）
- 每次失效需通过片上互连（如 Intel Ring Bus / AMD Infinity Fabric）广播信号 → 占用总线带宽
- 若锁变量与其它热点变量（如计数器、时间戳）共享同一缓存行，还会诱发 伪共享（False Sharing） → 进一步放大总线流量
- 高频率自旋锁（spinlock）更危险：线程在用户态空转轮询，持续发出 cache line read-modify-write 请求，使总线处于饱和状态
高频热点代码为何特别脆弱
所谓“热点”，意味着单位时间内该代码被成百上千次执行。一旦其中包含粗粒度同步原语，就会将局部竞争放大为系统级压力：
- 单个锁被每毫秒争抢数百次 → 每秒产生数千次缓存行迁移事件
- 10 个线程争同一把锁 → 平均每次成功加锁后立刻被下一线程抢占 → 出现“锁乒乓（lock bouncing）”现象
- JVM 中的偏向锁撤销、轻量级锁膨胀过程也需原子指令+内存屏障 → 触发总线锁定前缀（LOCK prefix）指令，直接占用总线周期
验证与定位的关键信号
不要只看 top 的 %CPU；关注这些指标才能确认是否落入“总线锁竞争过载”：
- perf stat -e cycles,instructions,cache-references,cache-misses,cpu/event=0x51,umask=0x01,name=offcore_response/：观察 offcore_response 数据是否异常高（说明大量请求溢出到环形总线或内存控制器）
- perf record -e mem-loads,mem-stores,mem-loads:u,mem-stores:u -g：识别哪些地址频繁触发跨核内存访问
- /sys/devices/system/cpu/cpu*/cache/index*/coherency_line_size：确认缓存行大小（通常 64 字节），辅助排查伪共享
- 使用 pidstat -t -w 1 发现某线程 cswch/s（上下文切换）远高于 nvcswch/s（非自愿切换）→ 表明大量线程主动让出 CPU 等待锁
