线程池/异步任务的并发度到底该定多少：CPU 核数派、Little 定律派、压测派，你们线上真的信哪个？

先抛背景。

我做过一个真实复盘：某订单中心一个异步落库任务，最初用固定 200 线程的线程池跑，CPU 一直不满 30%，看起来"很闲"。后来有人按"CPU 核数 × 10"的经验把池子扩到 2000 线程，结果 P99 从 180ms 飙到 2.4s，DB 连接池全部打满，下游出现雪崩式等待。回滚到 200 之后一切正常。

这件事让我纠结了很久：并发度到底是一个"参数"，还是一个"被系统其他部分反推出来的结果"？

我观察到大家大概分三派：

一、CPU 核数派。CPU 核数 × N（N 常取 2、10、50），简单、可解释、面试友好。问题是对 IO 密集型的 N 取多少，几乎全凭手感，而且完全忽略了下游（DB、RPC）的承载能力。

二、Little 定律派。L = λ × W，并发度 = 目标 QPS × 目标响应时间。逻辑很干净，但前提是你知道 λ 和 W，而 W 恰恰又受并发度影响——这是个闭环，实际调的时候很容易变成"我猜一个 W 然后反推一个 L，再压测发现 W 变了"。

三、压测/水位派。压到 P99 拐点，取拐点前的 80% 作为上限。最扎实，但需要一套稳定的压测环境 + 下游 mock 或影子库，小团队往往没有这个条件，就直接退化成派一了。

我的倾向：把并发度当成"下游瓶颈的前置约束"来定，而不是"上游吞吐的放大系数"。具体做法是——先测下游（DB/RPC）的单并发 P99 拐点，再按 Little 定律反推本地并发上限，最后留 20% 余量。CPU 核数只作为"线程创建成本"的软上限，不作为吞吐依据。

但我不确定的是：

1. 当下游本身弹性伸缩（比如 K8s HPA），你的"下游拐点"是动态的，本地并发度是不是应该跟着变？有没有人真的在做"并发度自适应"？
2. 异步任务（消息消费、定时批处理）和同步请求的并发度，你们会分开定吗？还是共用一套？
3. 有没有团队真的把 Little 定律用到了生产环境？用的时候最大的坑是什么？

欢迎贴你们线上的真实数字（脱敏即可），尤其是"调完之后 P99 反而变差"的案例——这种比成功案例有价值多了。