可安全调整核心线程数，但须满足：RUNNING 状态、标准 ThreadPoolExecutor、新值合法（1≤新值≤maximumPoolSize）；增大需预热或调用 prestartAllCoreThreads()，减小需启用 allowCoreThreadTimeOut(true)；生产环境须校验状态、活跃线程数、新值合法性，并对接配置中心与监控。
可以安全调整，但必须满足三个前提：线程池处于 RUNNING 状态、使用标准 ThreadPoolExecutor（或 Spring 的 ThreadPoolTaskExecutor）、新值合法（大于 0 且不超过当前 maximumPoolSize）。
增大核心线程数要主动预热
调用 setCorePoolSize(10) 不会立刻创建新线程。它只是更新阈值，后续行为取决于队列和任务压力：
- 若工作队列中有积压任务，线程池会立即启动新核心线程去消费
- 若队列为空，新线程只在下一次提交任务且当前活跃线程不足时才创建
- 如需“秒级扩容”，必须紧接着调用
prestartAllCoreThreads()，强制拉起所有未运行的核心线程
减小核心线程数需启用超时回收
把 corePoolSize 从 8 改成 4，不会中断任何正在执行的任务，但空闲线程默认永不退出：
- 必须提前设置
allowCoreThreadTimeOut(true) - 配合合理的
keepAliveTime（例如 30 秒），空闲核心线程才会在超时后自动终止 - 已提交但未执行的任务仍在队列中，不受影响
避免踩坑的关键检查点
动态调整不是简单的一行代码，生产环境必须做这几件事：
立即学习“Java免费学习笔记（深入）”；
- 确认当前线程池状态：
executor.getThreadPoolExecutor().isShutdown() == false - 检查当前活跃线程数：
executor.getActiveCount()，防止缩容后瞬间无法承接流量 - 校验新值合法性：不能小于 1，也不能大于
getMaximumPoolSize()；若需扩容上限，先调setMaximumPoolSize() - 对接配置中心（如 Nacos）监听变更，并同步上报 Prometheus 指标（如
thread_pool_core_size_current）
不建议动态修改的场景
高频抖动式调整会引发资源浪费和响应延迟：
- 避免在毫秒级波动中反复扩缩（如每秒调一次
setCorePoolSize） - 更适合按业务周期调整：例如大促前 10 分钟批量扩容，凌晨低峰期定时缩容
- 若底层是无界队列（如
new LinkedBlockingQueue()），corePoolSize是唯一并发控制杠杆，务必配强监控和告警
