线程池配置需精准匹配任务特征与系统资源：CPU密集型设corePoolSize为CPU核心数+1，IO密集型从CPU核心数×2起步并依压测调优，混合型须拆分隔离；队列首选有界ArrayBlockingQueue，容量按峰值QPS×平均耗时×1.5计算；maximumPoolSize设为corePoolSize的2–4倍，keepAliveTime推荐60秒；拒绝策略优选CallerRunsPolicy，线程工厂必须自定义命名，禁用Executors默认创建方式。
关键不是堆线程数量，而是让每个参数精准匹配任务特征和系统资源。盲目加大线程数反而会因上下文切换、锁竞争和内存压力拖垮吞吐。
按任务类型设对核心线程数（corePoolSize）
这是线程池的“常驻战斗力”，设高了白占资源，设低了压不住日常流量。
- CPU密集型（如加解密、数值计算）：设为 CPU核心数 + 1。多一个线程可应对偶尔的缓存未命中或系统调用阻塞，避免CPU空转
- IO密集型（如HTTP调用、数据库查询）：从 CPU核心数 × 2 起步，若平均IO等待时间长（比如300ms以上），可逐步试到 ×4；最终以压测时CPU利用率稳定在70%–85%为准
- 混合型（如电商下单链路）：不要混用一个线程池。把校验、库存扣减、支付通知等拆开，分别用不同线程池隔离——快计算任务不被慢IO拖住
选对有界队列并算准容量
无界队列（如默认的LinkedBlockingQueue）是吞吐隐形杀手——它把问题藏起来，直到OOM才爆发。
- 首选 ArrayBlockingQueue：容量固定、触发拒绝策略及时、便于监控告警
- 容量不是拍脑袋定的，建议公式：峰值QPS × 平均任务耗时（秒）× 1.5
例如：接口峰值100 QPS，平均处理200ms → 容量 ≈ 100 × 0.2 × 1.5 = 30，取32或64 - 慎用SynchronousQueue：只适合短平快任务（如日志异步落盘），且必须配够maximumPoolSize，否则任务直接被拒
- 绝对不用PriorityBlockingQueue：排序开销大，FIFO公平性被破坏，实测吞吐常降30%+
弹性伸缩靠最大线程数与存活时间协同
maximumPoolSize不是摆设，它是应对尖峰的“临时增援部队”，但必须可控。
立即学习“Java免费学习笔记（深入）”；
- 设为 corePoolSize 的 2–4倍（IO密集型可取上限），但硬上限别超 CPU核心数 × 8，防止调度开销反超收益
- keepAliveTime 推荐 60秒：足够回收突发创建的线程，又不会因毫秒级抖动频繁启停
- 对流量波动极大的后台服务，可开启 allowCoreThreadTimeOut(true)，让核心线程也参与回收（需配合非零keepAliveTime）
拒绝策略和线程工厂是稳定性底线
拒绝不是失败，是主动控流；看不见的线程名，会让线上排查变成噩梦。
- 生产环境优选 CallerRunsPolicy：当队列满+线程满时，由提交任务的线程自己执行，天然限流、不丢任务、不抛异常
- 务必自定义 ThreadFactory，给线程起有意义的名字（如“order-service-pool-%d”），出问题时一眼定位归属模块
- 禁用 Executors 工具类创建的线程池（newFixedThreadPool / newCachedThreadPool）：前者队列无界易OOM，后者线程无上限易触发频繁GC
