核心线程数需按任务类型精准设定：CPU密集型设为核数+1，IO密集型约为核数×2并压测调优，混合型应拆分隔离线程池；必须使用有界队列、合理拒绝策略及实时监控。
核心线程数不是拍脑袋定的数字，得看任务在 CPU 上“忙”还是在“等”。CPU 密集型任务几乎不等 IO，线程一跑就榨干 CPU；IO 密集型任务大部分时间卡在数据库响应、HTTP 调用或磁盘读写上，CPU 反而空着。选型的关键，是让线程数匹配这种真实运行状态。
CPU 密集型：宁少勿多，守住核数底线
这类任务（如加解密、图像压缩、实时计算）会让 CPU 持续满载。线程数超过逻辑核数，只会引发频繁上下文切换，吞吐不升反降。
- 核心线程数 = CPU 核心数 + 1（例如 8 核机器设为 9），+1 是为应对缺页中断、GC 暂停等偶发阻塞，避免 CPU 空转
- 最大线程数通常与核心数一致，不建议动态扩容——CPU 已满，再开线程只是添乱
- keepAliveTime 设为 0，因为不需要非核心线程
- 队列必须是有界队列（如 ArrayBlockingQueue(100)），容量不宜过大，防止任务堆积占用内存
IO 密集型：靠等待时间估算，并留出缓冲空间
一个 HTTP 请求耗时 300ms，其中真正 CPU 计算只占 10ms，其余 290ms 都在等响应——这 290ms 就是“可并行”的窗口。线程数要能覆盖这个等待缺口。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 核心线程数 ≈ CPU 核数 × (1 + 平均等待时间 ÷ 平均 CPU 工作时间)；更实用的做法是从 CPU 核数 × 2 起步，压测后逐步上调
- 最大线程数建议设为核心数的 1.5～2 倍，给突发流量留缓冲余地
- keepAliveTime 设为 60 秒左右，方便临时扩容的线程在空闲后及时回收
- 队列容量按 峰值 QPS × 平均 IO 耗时（秒）× 1.2～1.5 估算，禁用无界队列
混合型任务：别硬凑一个池，优先拆分隔离
一个接口既要验签（CPU 型）又要查三次库（IO 型），统一配池必然顾此失彼：CPU 型任务被 IO 阻塞线程长期排队，IO 型又因线程不足堆积。
立即学习“Java免费学习笔记（深入）”；
- 按主责拆池：验签、压缩走 CPU 优化池（core = 核数 + 1）；远程调用、DB 查询走 IO 优化池（core = 核数 × 2～3）
- 用 CompletableFuture.supplyAsync(task, executor) 显式指定执行器，不依赖默认线程池
- 若必须共用，保守按 IO 型配置，但必须监控 getActiveCount() 和 getQueue().size() —— 持续高位说明 CPU 型任务已在排队饿死
落地前必须守住的三条底线
再合理的线程数，配错配套策略也白搭。
- 禁用无界队列：LinkedBlockingQueue 默认 Integer.MAX_VALUE 容量，极易 OOM；务必显式指定容量
- 拒绝策略不能静默丢弃：生产环境推荐 CallerRunsPolicy（让提交线程自己执行，天然限流）或 AbortPolicy（抛异常，快速暴露问题）
- 监控三项指标：活跃线程数、队列积压量、拒绝任务数；发现持续排队或频繁拒绝，就得立刻调参
