Java 线程池最佳实践¶

线程池参数调优的核心思路：先“看清任务”（CPU/IO/混合）、再“算一个大致范围”、最后“用监控和压测不断微调”，而不是死记某个固定公式。

一般性硬规则（踩坑必看）¶

必须自己 new ThreadPoolExecutor，而不是直接用 Executors 快捷工厂（否则容易无界队列/无限线程 → OOM）。
一定使用有界队列（如 ArrayBlockingQueue、指定容量的 LinkedBlockingQueue），明确 queue 容量上限。
核心参数调优的“主战场”就是这 3 个：corePoolSize、maximumPoolSize、workQueue（类型+容量）。
生产环境要有监控：poolSize、activeCount、queueSize、completedTaskCount、任务耗时分布等，调优要靠数据，不靠感觉。

如何给线程数“算一个合理区间”¶

先分类任务类型
CPU 密集型：大部分时间在算（加解密、压缩、复杂计算）。
IO 密集型：大部分时间在等（网络 IO、磁盘 IO、RPC 调用）。
混合型：既有计算又有 IO。
经验公式与思路
通用参考公式（只作为起点）：
- 最佳线程数 ≈ N × (1 + WT / ST)，N 为 CPU 核心数，WT 为等待时间，ST 为计算时间。
简化成“记得住”的版本：
- CPU 密集型：corePoolSize ≈ CPU 核心数或 N+1。
- IO 密集型：corePoolSize ≈ 2N ~ 4N，甚至 N×M（M>1），视 WT/ST 比例调高。
实际做法：
1. 用压测或日志统计一个任务的“CPU 计算时间”和“整体耗时”，算粗略 WT/ST。
2. 用上面的公式算一个初始线程数，压测时从略小值开始逐步增大，找到 TPS 变平甚至下降前的那个点。
maximumPoolSize 一般策略：
- 不要随便设很大，只比 corePoolSize 高一小截，用来短时应对峰值。
- CPU 密集型：max ≈ core 或 1.5×core。
- IO/混合：max ≈ 2×core 或 2~3×core，再结合队列容量限制总负载。

队列类型和容量怎么选¶

队列类型 + ArrayBlockingQueue：有界数组队列，简单、可控，调优首选。 + LinkedBlockingQueue(有界)：链表有界队列，入队/出队性能好，但一定要限制容量。 + SynchronousQueue：不存任务，来一个就必须有线程接，一个不接就触发扩容或拒绝，适合短任务、高吞吐、希望快速失败的场景（如网关）。 + PriorityBlockingQueue/DelayQueue：有优先级或延时需求的专用场景，不要滥用。

队列容量经验原则： + 队列越大 → 峰值能兜住越多任务，但排队延迟越高，甚至撑爆内存。 + 队列越小 → 峰值时更早触发扩容或拒绝策略，延迟更稳定，但容易“失败得更快”。

常见做法： + 对“必须完成但对时延要求不极致”的任务（如异步写日志、报表生成）：队列可以略大，如几千级，但配合限流。 + 对“强实时接口请求”：队列要小甚至使用 SynchronousQueue，超载时尽快失败+降级，而不是堆积。

队列容量初值可根据：峰值 QPS × 允许排队时长（比如 1 秒）估算，再结合内存和业务可接受排队长度调整。

队列容量¶

经验原则：

队列越大 → 峰值能兜住越多任务，但排队延迟越高，甚至撑爆内存。
队列越小 → 峰值时更早触发扩容或拒绝策略，延迟更稳定，但容易“失败得更快”。

常见做法：

对“必须完成但对时延要求不极致”的任务（如异步写日志、报表生成）：队列可以略大，如几千级，但配合限流。
对“强实时接口请求”：队列要小甚至使用 SynchronousQueue，超载时尽快失败+降级，而不是堆积。

队列容量初值可根据：峰值 QPS × 允许排队时长（比如 1 秒）估算，再结合内存和业务可接受排队长度调整。

拒绝策略与业务等级¶

拒绝策略调优是“出问题时怎么优雅地掉下去”的关键。

关键业务（订单、支付、结算）：
- 优先 CallerRunsPolicy 或自定义策略（记录日志、上报监控、限流/降级），尽量避免悄悄丢任务。
非关键业务（异步统计、埋点、缓存预热）：
- 可用 DiscardPolicy 或 DiscardOldestPolicy，确保主流程不被拖死。
无论如何：不要默认 AbortPolicy 且不捕获异常；至少要打日志 + 告警，方便调优。

实际项目常见组合：

Web 接口业务线程池：CallerRunsPolicy，保护后端。
异步消息处理线程池：DiscardOldestPolicy 或自定义策略，把任务转入 MQ 重试。

监控 + 动态调优（生产必备）¶

光靠“启动参数”远远不够，成熟项目一定要做这两件事：

暴露线程池指标

定期打印或上报（Prometheus、Micrometer 等）：

poolSize / corePoolSize / maximumPoolSize
activeCount
queueSize、队列使用率
completedTaskCount、任务平均耗时与分布
拒绝次数、异常数

利用这些指标判断：

activeCount 一直接近 maximumPoolSize，queueSize 也比较大 → 线程数或队列太小。
activeCount 远小于 corePoolSize、CPU 利用率低 → 线程数可能太大或任务本身不够“忙”。
支持运行时动态修改

ThreadPoolExecutor 本身支持 setCorePoolSize、setMaximumPoolSize 等方法，美团方案就是把这些配置做成可动态下发（如结合配置中心 + 控制台）。

典型思路：

把线程池包装成“可配置 bean”，暴露一个刷新接口，从配置中心拉取新参数并调用 setXXX。
加上权限控制+参数校验（避免误操作调成 1w 线程）。

可直接套用的两个模板¶

下面给你两个可以直接改名用的“模板配置”，方便你在项目落地。你只需根据 CPU 核心数和业务特点微调。

模板一：CPU 密集型任务线程池适用：纯计算型，如批量加解密、规则引擎计算。

@Bean("cpuTaskPool")
public ThreadPoolExecutor cpuTaskPool() {
    int cores = Runtime.getRuntime().availableProcessors();
    return new ThreadPoolExecutor(
            cores,                      // corePoolSize
            cores + 1,                  // maximumPoolSize
            30L, TimeUnit.SECONDS,      // keepAliveTime
            new ArrayBlockingQueue<>(1000),
            new NamingThreadFactory("cpu-task-pool"),
            new ThreadPoolExecutor.AbortPolicy() // 配合监控+告警
    );
}

调优要点：

压测 CPU 利用率，目标 70%~85% 左右。
一旦 CPU 打满且响应时间变长，就别再加线程了，考虑拆业务或扩机器。

模板二：IO 密集型业务接口线程池（典型 Web 接口）

适用：调用下游服务/DB 的业务接口，想兜住高并发。

@Bean("ioBizPool")
public ThreadPoolExecutor ioBizPool() {
    int cores = Runtime.getRuntime().availableProcessors();
    int corePoolSize = cores * 2;
    int maxPoolSize = cores * 4;
    int queueCapacity = 2000;

    return new ThreadPoolExecutor(
            corePoolSize,
            maxPoolSize,
            60L, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(queueCapacity),
            new NamingThreadFactory("io-biz-pool"),
            new ThreadPoolExecutor.CallerRunsPolicy() // 保护后端
    );
}

调优要点：

压测下观察：队列长度、线程活跃数、接口 P99 耗时。
如果队列经常顶满且拒绝增加 → 考虑扩机器 / 限流 / 拆线程池。
如果线程一直不满，延迟也低 → 可以适当减少线程数，减少上下文切换。