corepoolsize是常态容量，maximumpoolsize是峰值上限；线程池按“创建核心线程→入队→扩容非核心线程→拒绝”顺序处理任务，仅在有界队列满且线程数未达maximumpoolsize时才扩容，否则该参数失效。
corePoolSize 和 maximumPoolSize 不是并列关系，而是“常态容量”与“峰值上限”的层级关系。线程池不会一上来就拉满 maximumPoolSize，它只在任务压力持续升高、队列又撑不住时，才逐步扩容到这个上限。
它们怎么协同工作
线程池处理新任务时，按固定顺序决策：
- 当前线程数 ＜ corePoolSize → 立即创建新核心线程执行（哪怕已有空闲线程）
- 当前线程数 ≥ corePoolSize 且队列未满 → 任务进队列等待
- 队列已满 且 当前线程数 ＜ maximumPoolSize → 创建非核心线程执行任务
- 队列满 + 线程数已达 maximumPoolSize → 触发拒绝策略
maximumPoolSize 在什么情况下失效
这个参数只在使用有界队列时真正起作用。常见误区是用 LinkedBlockingQueue 默认构造（容量为 Integer.MAX_VALUE），表面看是有队列，实则等于无界——此时任务永远优先入队，永远不会触发扩容逻辑，maximumPoolSize 形同虚设。
想让 maximumPoolSize 发挥作用，必须搭配 ArrayBlockingQueue 或指定容量的 LinkedBlockingQueue（比如 new LinkedBlockingQueue(100)）。
corePoolSize 和 maximumPoolSize 的典型差值逻辑
差值代表“弹性缓冲空间”，不是越大越好，要匹配业务节奏：
- CPU 密集型：两者通常相等（如都设为 CPU 核数），避免线程争抢 CPU 导致频繁切换
- IO 密集型：maximumPoolSize 可设为 corePoolSize 的 2–5 倍，应对网络延迟、DB 响应慢等不可控阻塞
- 突发流量场景（如秒杀）：corePoolSize 保持稳定，maximumPoolSize 设高些+小容量队列，靠快速扩容扛压，而非堆积任务
别忽略 allowCoreThreadTimeOut 的影响
默认情况下，corePoolSize 线程永不销毁。但若设置了 allowCoreThreadTimeOut(true)，那么所有线程（包括核心线程）都会受 keepAliveTime 约束。此时 corePoolSize 就退化为“初始线程数下限”，而 maximumPoolSize 才是真正的硬上限。
这种配置适合任务波动极大、空闲期长的后台批处理系统，能更激进地释放资源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
