共享 Tomcat 池混跑 CPU 密集与 IO 任务：P99 劣化时，靠什么指标判定「该加线程」还是「该拆池隔离」？有没有可操作的阈值？

【背景】 我负责一个 B 端 SaaS 的聚合服务（JDK 17，Tomcat max-threads=200，8C16G 容器），同一个 Tomcat 工作线程池里混跑两类任务：

• IO 型：一次请求扇出 3 个 RPC + 1 次 MySQL，下游 P50 都在 20ms 内，占请求量约 80%；
• CPU 密集型：报表导出接口，单请求要做 2~8 秒的聚合计算 + 大 JSON 序列化（报文 200KB~2MB），占请求量约 5%，但单请求吃满 1~2 个核。

【现象】 上线导出功能后，整体 P99 从 180ms 抖到 450ms+。但拆开看：导出接口自身 P99 只从 3s 涨到 5s（可以接受），而 IO 型接口 P99 恶化了 2.5 倍。直觉上判断是 CPU 密集任务占住了线程、挤占了 IO 请求的并发窗口，但线程池 active 数在抖动时段只有 90~130，远没到 200 上限——线程明明「没满」，为什么 IO 请求还在排队劣化？

【已尝试的排查】

1. 把 max-threads 从 200 加到 400：导出接口变快了，但 IO 接口 P99 反而再涨 30ms——疑似更多 CPU 密集任务并发跑，CPU 打满后上下文切换变多（perf stat 显示 context-switch 从 8k/s 涨到 22k/s）。
2. 看 ThreadMXBean 的线程状态分布：RUNNABLE 占比在抖动时段从 60% 掉到 30%——不确定这算「CPU 饥饿」还是正常的等 IO。
3. 考虑过把导出接口拆到独立服务或独立线程池，但团队没有先例，不知道拆完容量怎么算、会不会只是把问题搬家。

【期望得到的答案形态】

• 混跑场景下，「该加线程」和「该拆池」分别对应的可观测信号是什么？（例如：active 未满但 P99 劣化 + context-switch 上升 + RUNNABLE 占比下降，这个组合是不是 CPU 密集挤占的指纹？有没有更硬的指标，比如 runqueue 长度 / CPU steal / 每请求 CPU 时间占比？）
• 拆池（隔离）之后，两个池的容量各怎么算？有没有基于 Little's Law 或 CPU 时间占比的定量方法，而不是拍脑袋？
• 有没有人做过「拆池前 vs 拆池后」的对照压测数据？导出接口和 IO 接口各自的 P99 变化？

补充：虚拟线程（JDK 21）我们评估过，但导出接口的计算段是纯 CPU 密集，虚拟线程并不会让它变快，反而 carrier 池还是 8 个，所以我认为核心问题不在并发模型，而在「同池混跑的调度公平性」。