很多人第一次调线程池，最容易把问题简化成“线程数开大一点是不是就快了”。这通常是错的。线程池真正要解决的不是单纯把线程变多，而是在任务量、等待时间、CPU 能力和系统稳定性之间找一个可控边界。
直接 new Thread 的代价很高：线程创建和销毁有成本，线程过多会带来上下文切换，异常情况下还可能把机器资源打满。线程池的价值，是复用线程、管理队列、限制并发，并在系统扛不住时用拒绝策略把风险显式暴露出来。
线程池先看四个核心元素
理解线程池时，可以先抓四个对象：
- 线程池本身：管理正在工作的线程。
- 任务接口：
Runnable或Callable，负责描述要执行的任务。 - 任务队列：
BlockingQueue，放还没轮到执行的任务。 - 工作线程：从队列里取任务并执行。
可以把它想成“窗口加等待区”：窗口就是工作线程，等待区就是队列。请求来了，先看有没有空窗口；没有空窗口，就进入等待区；等待区也满了，再考虑是否加临时窗口；如果窗口和等待区都满了，就要触发拒绝策略。
这比单看 corePoolSize 更重要。因为线上出问题时，往往不是某一个参数错了，而是线程数、队列大小、任务耗时和流量峰值没有一起设计。
七个参数各自管什么
ThreadPoolExecutor 常见七个参数是：
corePoolSize
maximumPoolSize
keepAliveTime
unit
workQueue
threadFactory
rejectedExecutionHandler可以这样理解：
corePoolSize：常驻工作线程数量。maximumPoolSize：线程池允许扩张到的最大线程数。keepAliveTime和unit：非核心线程空闲多久后回收。workQueue：任务等待队列。threadFactory：线程创建方式，通常用来命名线程、设置异常处理。rejectedExecutionHandler：任务无法接收时怎么处理。
调参时不要只盯着 maximumPoolSize。如果队列是无界队列，线程池可能一直把任务塞进队列，根本不会扩到最大线程数，最后表现成延迟越来越高，甚至内存被队列拖垮。
线程数不是越多越好
线程数设置要先区分任务类型。
CPU 密集型任务主要在计算，线程太多只会增加上下文切换。经验起点可以按“CPU 核数 + 1”或“CPU 核数 × 2”估算，然后用压测修正。
IO 密集型任务会花大量时间等网络、磁盘、数据库或外部接口。等待时间越长，线程数可以适当更高，因为很多线程并不是一直占用 CPU。
一个常见估算公式是：
最佳线程数 ≈ ((线程等待时间 + 线程 CPU 时间) / 线程 CPU 时间) × CPU 核数比如 4 核机器，单个任务 CPU 时间约 20ms，等待时间约 80ms，那么起点可以估成：
(80 + 20) / 20 × 4 = 20这不是标准答案，只是一个起点。最终还是要看压测结果、平均响应时间、P95/P99、队列长度、拒绝次数和机器负载。
队列大小决定系统怎么背压
线程池稳定性很大一部分来自队列设计。
队列太小，高峰一来就容易触发拒绝；队列太大，表面上错误少了，但请求会在队列里排很久，用户看到的是超时，系统看到的是延迟堆积。
更稳的做法是给队列设置明确上限，并配合监控：
- 当前活跃线程数。
- 队列长度。
- 任务等待时间。
- 任务执行时间。
- 拒绝次数。
- 下游接口耗时。
如果队列持续增长，不要只想着加线程。先看任务是不是被下游卡住，是否有慢 SQL、慢接口、锁竞争或网络抖动。线程池只是把问题显性化，不会替业务消灭瓶颈。
拒绝策略不是异常分支，而是保护边界
常见拒绝策略包括抛异常、调用者执行、丢弃任务、丢弃最旧任务。实际业务里不要随便用“静默丢弃”，否则问题会变成数据不一致或任务消失。
我更倾向于把拒绝策略当作保护边界：
- 可以失败的请求，及时失败并返回明确提示。
- 可以降级的任务，转入降级逻辑或低优先级队列。
- 必须完成的任务，进入可靠消息或任务表，后续重试。
不要让线程池无限接活。系统容量有边界，拒绝策略就是告诉你“边界已经到了”。
Spring @Async 也要指定线程池
@Async 用起来很方便，但不能只加注解就结束。异步方法如果没有明确线程池，容易混用默认执行器，后续排查线程名、队列堆积和异常日志都会比较痛苦。
更稳的做法是：
- 用
@EnableAsync开启异步能力。 - 定义业务专属
ThreadPoolTaskExecutor。 @Async("executorName")明确指定线程池。- 给线程加可识别的前缀。
- 给异步异常和超时留出监控。
异步不是把任务扔到后台就万事大吉。只要任务仍然消耗 CPU、数据库连接、Redis 连接或外部接口配额，它就仍然是系统负载的一部分。
CompletableFuture 要注意默认线程池
CompletableFuture 很适合组合多个异步任务，例如并行查多个接口，再汇总结果。但它也有一个容易忽略的问题：不传 executor 时，很多方法会使用公共线程池。
在业务系统里，建议给重要异步链路显式传入自己的 executor。这样至少能做到：
- 不和其他公共任务互相抢资源。
- 出问题时能通过线程名定位来源。
- 可以单独配置队列、线程数和拒绝策略。
- 可以按业务重要性隔离不同任务。
另外，组合异步任务时要把异常处理写清楚。exceptionally、handle、whenComplete 这些方法不是装饰品，它们决定了部分任务失败时，整条链路到底是降级、兜底，还是直接失败。
小结
Java 线程池调参，先别急着背参数默认值。更实用的顺序是：
- 先判断任务是 CPU 密集还是 IO 密集。
- 再估算 CPU 时间和等待时间。
- 给线程数、队列和拒绝策略设置明确边界。
- Spring
@Async和CompletableFuture都要显式指定业务线程池。 - 最后用压测和监控修正，而不是凭感觉把线程数开大。
线程池不是越大越稳。真正稳定的线程池，是在系统忙起来时也能控制排队、暴露压力、保护下游。
