图 1：本文封面，滑杆就是线程数决策的直觉：往哪边滑、滑多少，得有依据。
线程池的线程数怎么设，几乎是每个后端都被问过的问题。最常见的答案是拍脑袋：「设 200 吧，先跑跑看。」然后某天流量翻倍，线程数不够，请求排队超时；或者反向翻车，线程开太多，上下文切换把 CPU 烧光， throughput 不升反降。这篇把「拍脑袋」换成一套可复用的方法论：公式给初值，压测做校准。
第一步，先分场景：你的任务是什么类型。
估算之前必须先回答一个问题：线程池里跑的任务，时间花在哪？
CPU 密集型任务——压缩、加密、序列化、数值计算——线程的每一毫秒都在占用 CPU。这时线程数的合理值约等于核数加一：核数个线程把 CPU 吃满，多出来的那个填补偶尔的缺页或切换空隙，再多就是纯浪费，徒增上下文切换。
IO 密集型任务——查数据库、调下游接口、读文件——线程大部分时间在等。这类场景的经典估算公式是：线程数 ≈ 核数 ×（1 + 等待时间 ÷ 计算时间）。一个任务如果 90% 的时间在等数据库返回、10% 在算，那么一个核理论上能喂饱约十个线程。
第二步，理解公式的直觉来源，而不是背它。
这个公式不是玄学，直觉就一句话：线程的价值，是在 CPU 空等 IO 时顶上别的任务。一个线程等待占比越高，CPU 闲置的窗口就越多，就能容纳越多线程轮流使用它。
同一个结论还有一个更工程化的表达——Little 定律的直觉版：所需线程数 ≈ 目标吞吐 × 单个任务的端到端耗时。举例：目标是每秒处理 1000 个请求，每个请求平均耗时 200 毫秒，那么任意时刻在途的请求约 200 个，你就需要约 200 个线程去承载它们。公式和定律说的是同一件事，一个从利用率切入，一个从吞吐切入，可以互相验算。
第三步，压测校准：估算只配当初值。
所有公式都有共同的软肋：等待时间、计算时间、下游响应，全是估出来的。所以正确姿势是把公式结果当初值，然后进压测闭环：逐步加压，同时盯两个指标——CPU 利用率和响应时间。如果吞吐还在涨、响应时间还平稳，说明线程数或流量还没顶到边；如果吞吐不再上升、响应时间开始恶化，而 CPU 远没打满，瓶颈多半不在线程数，在下游或连接池；如果 CPU 打满、吞吐到顶，回调线程数看是否回升。循环几轮，指标稳定下来的那个值，才是你的答案，而不是公式算出来的那个。
第四步，别忘了线程数之外的天花板。
线程池不是孤岛。线程数设到 500，数据库连接池只有 50，那么多出来的 450 个线程全在排队等连接，等于白设。下游接口的承载能力、队列长度、单线程的内存栈占用，都是约束的一部分。容量估算的正确单位不是「这个池子多大」，而是「这条调用链上最窄的环节在哪」。
图 2：场景估算、直觉来源与压测校准闭环。
三个常见误区
误区一：线程越多越好。超过拐点之后，再加线程增加的只有上下文切换开销和栈内存占用，吞吐反而下降。线程数是一条先升后降的曲线，不是单调上升的直线。
误区二：把公式当结论。「等待时间占九成」这个输入本身就带着巨大误差，不同接口、不同流量画像下差异极大。公式的价值是给你一个不离谱的起点，省掉的是瞎猜，不是压测。
误区三：只算不管。线上流量画像会漂移——大促、新功能、下游变慢都会让当初校准的值失效。把线程池的核心指标（活跃线程、队列深度、拒绝次数）接进监控，容量结论才有保质期。
给你的行动建议
挑一个你负责的服务做一遍完整练习：先判断主任务是 CPU 密集还是 IO 密集，用公式算出初值，再用 Little 定律从目标吞吐反推验算，两个数差出一个量级说明你对任务的理解有偏差。然后安排一次压测，画出「线程数—吞吐—响应时间」三条曲线，找到拐点。这套流程走一遍，比背十个公式都管用——下次面试被问「线程数怎么设」，你答的就是方法论而不是数字。
你现在的服务线程池参数是算出来的、压出来的，还是继承下来的？欢迎对号入座。