java线程池仅corepoolsize、maximumpoolsize和keepalivetime可动态调整：setcorepoolsize()调大不立即创建线程，调小需allowcorethreadtimeout(true)才回收空闲核心线程；setmaximumpoolsize()调小限制新非核心线程创建，调大提升弹性上限；setkeepalivetime()配合超时配置影响缩容效果。
Java 中线程池可以动态修改核心参数，但仅限于部分参数，且行为有明确边界——核心线程数（corePoolSize）和最大线程数（maximumPoolSize）支持运行时调整，而队列容量、拒绝策略、线程工厂等不可动态变更。
哪些参数能动？怎么动？
ThreadPoolExecutor 提供了公开的 setter 方法：
-
setCorePoolSize(int)：重设核心线程数。调大后不会立即创建新线程，只在后续任务提交且队列积压或空闲线程不足时逐步触发；调小后也不会中断正在运行的线程，超出部分需等待空闲超时才退出（前提是已启用
allowCoreThreadTimeOut(true)） - setMaximumPoolSize(int)：重设最大线程数。调小会限制后续非核心线程的创建，已存在的超额线程会在空闲后回收；调大可为突发任务提供更高弹性上限
-
setKeepAliveTime(long, TimeUnit)：可动态更新非核心线程的空闲存活时间，配合
allowCoreThreadTimeOut对缩容效果至关重要
为什么调了没反应？常见失效原因
很多开发者调用 setCorePoolSize() 后发现线程数没变，往往是因为忽略了以下关键点：
- 未调用
prestartAllCoreThreads()：调大 corePoolSize 后，若没有新任务持续提交，线程池不会主动“预热”新建核心线程 - 未设置
allowCoreThreadTimeOut(true)：默认情况下，核心线程永不超时退出，即使 corePoolSize 被调小，空闲核心线程仍长期驻留 - 使用了无界队列（如
LinkedBlockingQueue无参构造）：任务永远优先入队，几乎不触发线程扩容逻辑，使 corePoolSize 调整失去意义 - 线程池处于
SHUTDOWN或更严格状态：虽然setCorePoolSize仍可调用，但不再创建新线程，实际效果受限
生产环境安全调优的关键动作
动态调整不是简单改个数字，而是需要配套机制保障可观测与可控：
- 接入配置中心（如 Nacos/Apollo），监听配置变更事件，避免人工登录服务器操作
- 封装校验逻辑：确保新
corePoolSize不超过maximumPoolSize，且大于 0 - 调整后同步触发
prestartAllCoreThreads()（扩容时）或记录待回收线程数（缩容时） - 对接监控系统，跟踪
getActiveCount()、getQueue().size()、拒绝数等指标，形成闭环反馈
一句话总结落地要点
动态修改核心参数是可行的，但必须理解它只是“重定义规则”，不是“立即执行指令”；真正生效依赖任务流量、队列状态、超时配置与主动触发动作的协同——没配 allowCoreThreadTimeOut 的缩容，和没调 prestartAllCoreThreads 的扩容，基本等于没调。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
