线程生命周期的物理转换边界由操作系统调度器在硬件事件触发下强制执行，核心表现为运行→阻塞批量挂起、阻塞→就绪脉冲唤醒、就绪态排队导致隐性调度压力。
线程生命周期的物理转换边界，本质上是操作系统调度器对线程状态变更的硬性响应点——它不依赖代码逻辑，而是由内核在真实硬件事件（如中断、时钟滴答、I/O完成通知）触发下强制执行的状态跃迁。当网络出现极端抖动（例如 RTT 从 1ms 突增至 800ms，丢包率瞬时超 40%），大量线程会在“运行 → 阻塞”和“阻塞 → 就绪”这两个关键边界上发生密集、非均匀的批量切换，直接扰动 CPU 核心的负载分布曲线。分析这种扰动，需聚焦三个可观测、可归因的物理边界行为：
1. 运行态到阻塞态的批量挂起，引发核心瞬时空载与队列堆积
网络抖动导致 socket read/write 等系统调用频繁进入不可中断睡眠（UNINTERRUPTIBLE_SLEEP / D 状态），尤其在阻塞 I/O 模型下。此时线程不是主动让出 CPU，而是被内核强制挂起并移出运行队列。其物理表现是：
- 单个核心上 runq-sz（运行队列长度）骤降为 0，但 procs-b (blocked 进程数) 在 /proc/stat 中突增；
- 该核心的 %sys 使用率短暂冲高（因内核处理中断和唤醒等待），随后跌入低谷（无就绪线程可调度）；
- 若线程池使用有界队列（如 ArrayBlockingQueue），任务提交线程可能在 offer() 调用中自旋或阻塞，进一步加剧同核竞争。
2. 阻塞态到就绪态的延迟唤醒，造成核心负载“脉冲式回填”
抖动缓解后，内核收到网卡中断，批量唤醒因 socket 事件阻塞的线程。但由于抖动期间积压了大量等待连接/数据的线程，唤醒并非平滑，而是集中在几个时间片内爆发：
- vmstat 1 显示 cs（上下文切换数）在几秒内翻倍甚至十倍，且常伴随 in（中断数）同步激增；
- perf record -e sched:sched_wakeup 可捕获到大量 wakeups 在毫秒级窗口内扎堆，说明多个线程被同一软中断（如 net_rx_action）统一唤醒；
- 若未绑定 CPU 亲和性，这些被唤醒的线程可能被调度到不同核心，导致 L3 缓存失效率陡升（用 perf stat -e cache-misses,cache-references 观测），表现为各核心负载曲线出现不同步的尖峰。
3. 就绪态排队等待调度的“隐性阻塞”，暴露调度器压力与 NUMA 不平衡
唤醒后的线程进入就绪态（Runnable），但未必立刻获得 CPU。此时它们在 CFS 运行队列中排队——这个排队过程虽不显式阻塞，却是负载曲线失真的主因：
- 使用 pidstat -w 1 查看特定线程的 %wait 字段，若持续 >30%，说明就绪但长期得不到调度，反映运行队列过长或优先级被压制；
- 在 NUMA 架构下，若网络中断落在节点 0，而应用线程默认在节点 1 运行，就绪线程会跨节点排队，numastat -p <pid> 显示 node1 的 numa_hit 远低于 numa_miss，此时即使 CPU 利用率不高，实际吞吐也受限；
- 结合 mpstat -P ALL 1，常可见部分核心 %idle 接近 0 且 %iowait 微升，而其他核心 idle 较高——这不是负载均衡失败，而是就绪线程被锁在本地运行队列中，尚未被 load balance 机制迁移。
不复杂但容易忽略：网络抖动本身不消耗 CPU，但它通过强制线程在运行↔阻塞↔就绪之间的物理边界反复横跳，把延迟问题转化成了调度器的瞬时压力问题。真正决定 CPU 负载曲线形态的，不是抖动幅度，而是线程在这些边界上的批量性、同步性和跨核分布性。
