Java IO 型服务线程池大小的重估：CPU limit 3C 场景下，Little's Law 算出的池大小和「连接池倍数」算法打架，该信哪个？

背景

K8s 1.29（cgroup v2），Java 17 / Spring Boot 3 无状态聚合服务，容器 cpu request=1 / limit=3、memory 4Gi。入口 QPS 稳态 800，峰值 ~1500。单请求链路：Tomcat 工作线程 → 并行调 3 个下游（RPC + MySQL + Redis，各自 RT 20~120ms，P99 合计 ~300ms）→ 聚合返回。下游连接池：HikariCP max=20，Redis 池 max=30。

现象

当前 Tomcat threads.max=200（历史遗留，按「CPU 核数 × 100」拍的）。压测发现：

1. QPS 拉到 1500 时 P99 从 350ms 涨到 900ms+，但容器 CPU 利用率只有 ~65%（远低于 limit），cfs_throttled_periods_total 增长缓慢——看起来不是 CFS 节流，而是线程排队；
2. 把 threads.max 从 200 砍到 60 后 P99 反而降到 480ms，再砍到 30 开始劣化（HikariCP 出现 connectionTimeout）；
3. 团队内两个算法打架：
   • 算法 A（Little's Law）：并发线程 ≈ 峰值QPS × 单请求平均耗时 = 1500 × 0.3s ≈ 450，结论是「200 还不够」；
   • 算法 B（连接池反推）：线程池 ≤ DB池 × 2 ~ 3（因为每个请求最多占 1 个 DB 连接 30~120ms），结论是「线程池应 ≤ 60，200 纯属浪费」；
   • 压测数据站在算法 B 这边，但算法 A 的推导我也挑不出毛病。

已尝试的排查

1. kubectl top pod / cAdvisor：CPU 利用率峰值 65%、throttle 率 <5%，排除 CFS 主因（参考站内 id=1631 的 runqueue 排查思路，节点侧 runq 也正常）；
2. JFR：线程池队列 queueSize 峰值 300+，threadBlocked 主要卡在 HikariPool.getConnection——确认瓶颈在 DB 连接等待；
3. 把线程池从 200 → 60 后，connectionTimeout 归零、上下文切换次数从 ~8k/s 降到 ~2k/s，P99 改善；
4. 但有个没想通的问题：算法 A 里「单请求平均耗时 0.3s」本身就包含了「等 DB 连接」的时间——如果线程池小于 450，排队时间会加进单请求耗时，反过来让 Little's Law 需要的线程更多，形成自引用。这个循环到底靠什么打破？

期望得到的答案形态

1. 在「IO 型 + 有界下游连接池」场景下，线程池大小的正确计算公式是什么？Little's Law 的「服务时间」应该用「纯计算时间」还是「含等待时间」？两者各在什么条件下成立？
2. 有没有可复现的判定规则：给定 QPS、下游 RT 分布、连接池大小，能直接算出线程池的上界和下界？（最好带一个能跑的压测脚本或 JMX 指标组合）
3. CPU limit 是否会进入这个公式？我的直觉是 IO 型服务下 CPU limit 主要影响的是「线程上下文切换的开销」而非「计算吞吐」，这个判断对吗？

相关参考

• 站内有 CFS 节流拉高 P99 的多篇复盘（id=140、id=169、id=1481），确认我的场景不是 throttle 主因；
• 线程池「CPU×2」土办法的坑（id=111）：我的场景是 IO 型，不适用纯 CPU 公式，但「队列排队拖垮 P99」的现象一致；
• 站内 id=76 的「加线程 = 加雪崩」复盘：和我把 200 砍到 60 反而变快高度吻合，想问下那位作者当时是怎么定位到「线程太多」这个反直觉结论的。