核心线程数和最大线程数需依任务类型、资源瓶颈与队列行为协同设定：CPU密集型设core=CPU+1、max=core；IO密集型core≈CPU×2、max受下游限制；混合型用利特尔定律估算并压测验证；maximumPoolSize生效前提是有界队列。
核心线程数（corePoolSize）和最大线程数（maximumPoolSize）不能凭经验拍脑袋定，得看任务特性、资源瓶颈和队列行为三者联动。关键不是“设多大”，而是“为什么这么设”。
先分清任务类型，再选基数
任务性质决定线程池的“呼吸节奏”：
- CPU密集型（如实时计算、图像编码、加解密）：线程基本不等待，全靠CPU算力。corePoolSize建议设为 CPU核心数 + 1（+1是为应对偶尔的调度抖动），maximumPoolSize通常与corePoolSize相等——多开线程只会加剧上下文切换，徒增开销。
- IO密集型（如数据库查询、HTTP调用、文件读写）：线程常卡在等待响应上。corePoolSize可设为 CPU核心数 × 2起手；maximumPoolSize需结合下游承载力来定，比如数据库连接池只有50个连接，那maximumPoolSize再高也没用，反而引发排队或超时。
- 混合型（如Web接口：前端渲染+后端查库+调第三方）：不能简单套公式。推荐用利特尔定律粗估：max ≈ CPU核心数 × (1 + 平均IO等待时间 / 平均CPU计算时间)，再通过压测验证。
注意队列对 maximumPoolSize 的实际影响
maximumPoolSize是否真正生效，取决于workQueue的类型和容量：
- 用 LinkedBlockingQueue 且没指定容量（即默认 Integer.MAX_VALUE）→ 队列几乎无限 → 新任务永远进队列，线程数永远卡在corePoolSize，maximumPoolSize形同虚设。
- 用 ArrayBlockingQueue(100) 或 SynchronousQueue → 队列满后才会触发扩容逻辑 → 此时maximumPoolSize才起作用。
- 所以，想让maximumPoolSize有意义，必须配**有界队列**，否则扩再多线程也没机会创建出来。
避免两个典型误配
这些配置看似合理，实则埋雷：
立即学习“Java免费学习笔记（深入）”；
- corePoolSize设得过大（比如32核机器直接设64）：常态下就占满大量线程栈内存（每个线程默认1MB），还可能打爆数据库连接池或HTTP客户端连接数，导致下游拒绝服务。
- maximumPoolSize远大于corePoolSize但配无界队列：既浪费资源，又掩盖了真实瓶颈——你以为在“弹性扩容”，其实只是任务全堆在队列里慢慢腐烂，延迟越来越高，直到OOM。
- 更稳妥的做法是：初期按业务预期QPS和平均响应时间估算初始值，上线后紧盯 活跃线程数、队列积压量 和 拒绝任务数，用监控数据反推调整。
可以动态调，但别滥用
ThreadPoolExecutor支持运行时修改corePoolSize和maximumPoolSize：
- setCorePoolSize() 调大时，会立即创建新线程去消费队列里的积压任务；调小时，多余线程空闲后自动回收。
- setMaximumPoolSize() 调大后，只有在队列已满+当前线程数未达新上限时，才会新建线程。
- 但注意：队列容量不可动态改，必须初始化时定死。动态调整适合流量有明显峰谷的场景（如定时批处理），日常服务建议稳态配置+监控告警，而非高频自动扩缩。
