线程池大小不能仅依据cpu核数设定，需区分cpu密集型（≈核数+1）和io密集型（≈核数×(1+等待时间/cpu时间)，通常取2~4倍），并结合队列类型、拒绝策略及动态监控调优。
线程池大小不能只看CPU核数
很多人直接套用 Runtime.getRuntime().availableProcessors() 当作线程数，这是错的。CPU核数只反映并行计算能力，而实际任务往往包含IO等待、锁竞争、内存GC停顿等非CPU耗时。线程数设得太小，吞吐上不去；设得太大，线程上下文切换开销反而拖慢整体性能。
区分CPU密集型和IO密集型任务再计算
关键看任务执行时CPU是否持续忙碌：
- CPU密集型（如图像压缩、科学计算）：线程数 ≈
availableProcessors() + 1。+1是为了在某个线程因缺页或GC短暂阻塞时，仍有线程可调度 - IO密集型（如HTTP调用、数据库查询、文件读写）：线程数 ≈
availableProcessors() * (1 + 平均等待时间 / 平均CPU工作时间)。实践中常取availableProcessors() * 2 ~ 4，但必须结合压测验证
例如：8核机器跑大量远程HTTP请求（平均等待300ms，CPU处理仅10ms），理论值 ≈ 8 * (1 + 300/10) = 248，但实际可能只需64～128——因为连接池、网卡、服务端限流才是瓶颈，不是本机线程数。
用ThreadPoolExecutor构造时别忽略队列和拒绝策略
线程数只是参数之一，corePoolSize、maximumPoolSize、workQueue、handler 四者联动才决定真实行为：
立即学习“Java免费学习笔记（深入）”；
- 用
LinkedBlockingQueue且不设容量上限 →maximumPoolSize形同虚设，永远只创建corePoolSize个线程 - 用
SynchronousQueue→ 新任务直接触发扩容，直到达到maximumPoolSize，此时若再提交会触发拒绝策略 - 拒绝策略选
AbortPolicy（抛RejectedExecutionException）比默认静默丢弃更利于暴露容量不足问题
没配对的队列类型和拒绝策略，再“合理”的线程数也算白搭。
动态调整比静态公式更可靠
线上流量波动、依赖服务响应变慢、JVM GC频率升高都会让“最佳线程数”漂移。硬编码一个数字不如：
- 用
ThreadPoolExecutor.setCorePoolSize()和setMaximumPoolSize()在运行时调整 - 通过Micrometer或Prometheus监控
getActiveCount()、getQueue().size()、getCompletedTaskCount() - 当队列持续积压 + 活跃线程已达上限 → 扩容；当活跃线程长期低于核心数且响应快 → 缩容
公式只是起点，真实系统的线程池大小永远在压测、监控、调优的闭环里浮动。别信“一算就灵”，要信“一压就明”。
