Java线程池核心线程数支持运行时动态修改，但需满足RUNNING状态、标准ThreadPoolExecutor及新值合法三条件；增大时需配合prestartAllCoreThreads()预热，减小时须启用allowCoreThreadTimeOut(true)并设keepAliveTime。
Java线程池的核心线程数（corePoolSize）完全支持运行时动态修改，无需重启服务——这是生产环境应对流量峰谷、实现资源弹性伸缩的关键能力。但直接调用 setCorePoolSize() 并不等于“立刻扩容或缩容”，它的行为受线程池状态、队列类型、空闲策略等多重机制约束，必须结合配套操作才能真正生效。
动态修改的前提条件
调用 setCorePoolSize() 要真正起效，需同时满足三个硬性条件：
- 线程池必须处于 RUNNING 状态（
SHUTDOWN后仅允许缩容，STOP及之后状态下调用无效） - 使用的是标准
ThreadPoolExecutor或其子类（如 Spring 的ThreadPoolTaskExecutor） - 新值合法：大于 0，且不能超过当前
maximumPoolSize（扩容前务必确认最大值足够，否则会抛出IllegalArgumentException）
增大核心线程数的正确姿势
调大 corePoolSize 不会自动创建新线程，它只是“重定义后续创建规则”。若希望立即生效，必须主动触发预热：
- 调用
setCorePoolSize(newSize)更新阈值 - 紧接着调用
prestartAllCoreThreads()—— 这会强制启动所有未运行的核心线程（包括新增部分），立即提升并发处理能力 - 适用于突发流量场景，例如大促开始前批量扩容
减小核心线程数的回收逻辑
调小 corePoolSize 不会中断任何正在执行的任务，但空闲线程不会立刻退出：
立即学习“Java免费学习笔记（深入）”；
- 超出新值的空闲核心线程会被标记为“可回收”，但默认永不销毁（即使空闲）
- 必须提前设置
allowCoreThreadTimeOut(true)，并配合合理的keepAliveTime（如 30 秒），空闲线程才会在超时后自然退出 - 已提交但未执行的任务仍保留在队列中，不受影响
生产级落地关键点
脱离监控和校验的动态调整是危险的。真实环境中需闭环管理：
- 对接 Nacos/Apollo 等配置中心，监听
thread-pool.xxx.core-size变更事件 - 回调中做合法性校验（范围检查 + 与
maxPoolSize比较） - 同步更新 Prometheus 指标（如
thread_pool_core_size_current{pool="order"}） - 重点关注联动指标：当
activeCount长期接近corePoolSize且队列填充率 >70%，才是扩容信号
