每秒十六万次。我盯着 vmstat虚拟内存统计工具输出里 cscontext switch上下文切换那一列看了好几秒又跑了一遍命令怕自己眼花。旁边小刘凑过来问这个数很大吗我说这么讲吧一台正常的业务机这一列通常在几千到几万之间十六万的意思是CPU 每秒被换岗十几万次光忙着交接就够它呛哪还有工夫干活。这是上周三下午的事还是那家电商 SaaS多租户软件服务客户还是小刘——上回是服务凭空蒸发这回换了种憋屈法服务活着端口通健康检查一路绿就是所有请求全在干等接口 P9999% 请求的最大耗时从 80 毫秒涨到快 3 秒。更怪的是 top 一看CPU 才用了 45%。小刘的原话机器都没忙起来它慢什么呢先说这个换岗是怎么回事。CPU 同一时刻只能真跑一个线程你看到同时跑几十个其实是内核在飞快轮换让 A 上台跑几毫秒记下它干到哪了换 B 上再换 C。这套动作就是上下文切换。单次切换不贵微秒级的事但代价藏在看不见的地方——你桌上的资料会被全部收走。线程被切出去再切回来CPU 缓存L1/L2 cache可以理解成 CPU 手边的便签本早被别的线程写得面目全非TLB虚拟地址翻译的缓存也清空了你的线程等于从冷水灶重新热车。切换少的时候这点损耗无感切换一多CPU 的大部分力气全花在收拾桌子上真正的活反倒没人干——上篇结尾我说内核忙得脚不沾地却没干正事说的就是它。顺着往下查。vmstat 1 看全局cs 十六万多in每秒中断数也偏高pidstat -w -p 1 把范围缩到那台 Java 服务上cswch/s自愿切换自己让位的和 nvcswch/s非自愿切换时间片用完被撵下台的各占一半。jstackJava 自带的线程快照工具一抓五百多个线程一半 WAITING 在同一把锁上另一半 RUNNABLE——runnable 得特别均匀均匀得像提前排练过。线程哪来的翻发布记录头天晚上上了一批性能优化有人把核心服务的线程池从 64 改到了 512理由写的是充分利用多核。这逻辑听着没毛病坏就坏在它对了一半。核就 8 个512 个线程抢 8 张工位每人分到的时间片time sliceCPU 连续干活的额度被摊薄到几毫秒一个线程刚把缓存焐热就被换下去下一轮再上来又是一手冷水灶。再加上那段被一起带出来的全局锁——订单校验加了把 synchronizedJava 的互斥锁抢不到锁的线程全睡在 futex内核的等待队列机制上锁一释放又被批量叫醒醒了一看还没轮到自己接着睡。睡、醒、抢、再睡每来一回就是一串切换账就是这么滚到十六万的。插一嘴改线程池那位后来在复盘会上说他是看隔壁组也调大了才跟着调的。隔壁组调没调我不知道反正那两天他们组的告警群也挺热闹。修复就顺理成章了。线程池回 64——这服务是 CPU 密集型线程数给到核数的 1 到 2 倍基本就到头了那把全局锁拆掉按商户维度分片让不同商户互不干涉。当晚灰度上线vmstat 再看cs 掉回九千P99 第二天回到 90 毫秒上下。同样的机器同样的流量少的不是活是换岗。对了说个我自己的黑历史。我刚工作那会儿迷信线程就是马力恨不得一核开一百个线程觉得那叫榨干性能。直到有次压测线程数翻倍QPS每秒请求数反而腰斩盯着监控研究了半天才认真读完 cs 这一列。从那以后我改了个习惯看机器先看切换再看使用率——使用率只告诉你 CPU 忙不忙切换才告诉你它在忙什么。有几处容易误判的地方得说清楚免得你拿去乱套。有的服务切换天生就高做大量短连接的网关、做消息分发的几十万 cs 未必是病跟自己的基线比才有意义。容器里还有个长得像的变体cgroup 的 CPU 配额cpu.max每 100 毫秒发一次额度用完了内核就把整组线程冻结到下一个周期这叫 throttled被限流表现同样是服务活着、全在干等而且 CPU 使用率会恰好钉死在配额线上——你要是看到使用率永远精确停在限额值先查 throttle 统计别急着骂线程池。谁适合把这套排查吃透写高并发后端、管 JVM 线程池、或者做容器资源规划的建议把 vmstat 和 pidstat 这两条命令刻进肌肉记忆这种病在压测期就能按住。如果你的服务 QPS 常年两位数、框架配置从没动过知道切换也是成本这个概念就够了真碰上了再回来翻。至于还坚信线程越多越快的同学你不是不会调优你是在给 CPU 组织斗殴。收尾留个问题你见过最离谱的一次不忙但慢最后揪出来的是什么评论区聊聊这类问题的答案十有八九不在业务代码里。预告这回抢 CPU 的好歹都是你自己家的线程还有种更冤的情况你的代码一行没改网卡收包的杂活把 CPU 吃掉一半而干这活的线程在 top 里叫 ksoftirqd内核软中断线程专门处理网卡这类硬件的零碎活名字你八成没注意过。下篇聊聊软中断风暴那些不挂在你进程名下的隐形负载。