corePoolSize 不能热更新，因其为 final 字段；所谓动态调整实为调用 setCorePoolSize()，需满足未 shutdown 且新值不小于当前活跃线程数，否则静默失败，需手动校验状态。
corePoolSize 真的能热更新吗？先看 ThreadPoolExecutor 的设计约束
不能直接“热更新”——corePoolSize 是 final 字段，构造后不可变。所谓“动态调整”，本质是调用 setCorePoolSize(int) 方法触发内部重配置逻辑，但该操作有明确前提：线程池未 shutdown，且新值不小于当前活跃线程数（否则会主动中断空闲线程）。很多配置中心方案卡在这一步，不是配置没推下去，而是 setCorePoolSize(2) 被调用时线程池里已有 5 个活跃线程，方法静默失败。
-
setCorePoolSize(int)不抛异常，只做校验后返回，必须手动检查是否生效 - 若新值 < 当前
getActiveCount()，旧线程不会被回收，直到它们自然退出或超时 - 配置中心推送后，需同步调用
getPoolSize()和getActiveCount()核对状态
配置中心变更后，如何安全触发 setCorePoolSize
关键不在“怎么推配置”，而在“谁来调用 setCorePoolSize”以及“调用时机是否合理”。Spring Cloud Config / Nacos / Apollo 都支持监听变更，但监听回调里直接写 threadPool.setCorePoolSize(newVal) 很危险：可能并发多次调用、与线程池自身扩容逻辑冲突、或在 shutdown 过程中误触发。
- 监听回调必须加锁（如
ReentrantLock），防止重复设置 - 推荐封装成原子操作：
if (newVal != current && !isShutdown()) { setCorePoolSize(newVal); } - 避免在
afterPropertiesSet()或 Bean 初始化阶段硬编码设置，应等配置中心 ready 后再绑定监听
为什么 setCorePoolSize 后线程数没立刻变化？看 execute() 里的真实分支
调用 setCorePoolSize(8) 后，你看到 getPoolSize() 还是 3，并不意味着失败。ThreadPoolExecutor 的 execute(Runnable) 方法里有三段式逻辑：先尝试加核心线程 → 再入队 → 最后加非核心线程。只有新任务进来，且当前线程数 < 新 corePoolSize，才会真正创建线程。空闲线程池不会自动补足到新 core 值。
- 线程池“冷态”下，
setCorePoolSize(10)不会立即起 10 个线程，只改阈值 - 想立刻生效？发一个 dummy 任务触发扩容，或调用
prestartAllCoreThreads()（它会无视当前活跃数，强制启动 corePoolSize 个线程） - 注意
prestartAllCoreThreads()在已 shutdown 的池上会返回 0，需前置判断
Nacos 监听 + Spring Bean 生命周期配合的最小可行写法
不要试图全局代理所有 ThreadPoolExecutor，优先改造你实际管理的线程池 Bean。以 Spring Boot 为例，用 @RefreshScope 不够，因为它只重建 Bean，而线程池实例不能重建（会丢任务）。正确做法是持有引用，在监听里调用方法。
立即学习“Java免费学习笔记（深入）”；
- 在配置类里定义
@Bean返回ThreadPoolTaskExecutor，并暴露其getThreadPoolExecutor() - 用
@NacosConfigListener(dataId = "xxx")或@EventListener监听配置变更事件 - 回调里拿到新
core-size后，先if (newVal > 0) executor.getThreadPoolExecutor().setCorePoolSize(newVal); - 加一行日志：
log.info("corePoolSize updated to {}, active={}", newVal, executor.getActiveCount());
线程池参数热更新最易忽略的点：不是 set 成功就万事大吉，而是得确认后续任务是否真走新逻辑路径——比如队列满时是否按新 core 值扩容，而不是卡在旧阈值里等待。这需要结合压测和线程 dump 验证，不能只信日志。
