线程池核心参数不支持配置热更新，需通过配置中心推送→监听→调用setXXX()→状态同步闭环实现；应选用Nacos/Apollo，绑定DataId/Group，加可重入锁，避免初始化硬编码，且setCorePoolSize()触发JDK内部校验与调度。
线程池核心参数（corePoolSize、maximumPoolSize、queue capacity）无法靠“改完配置就自动生效”实现热更新——它们不是普通 Spring 属性，而是 ThreadPoolExecutor 实例内部的状态变量。真正可行的秒级热更新，是“配置中心推送 → 应用监听 → 安全调用 setXXX() 方法 → 主动触发状态同步”，整个链路必须闭环且防错。
配置中心选型与监听机制要可靠
优先选用 Nacos 或 Apollo，二者均支持服务端推（而非轮询），变更延迟稳定在 500ms 内。关键不在“能不能推”，而在“推到哪、谁来响应”：
- 监听必须绑定到具体
DataId和Group，避免全局配置变更误触线程池逻辑 - 使用
@NacosConfigListener（Nacos）或@ApolloConfigChangeListener（Apollo），不要在@PostConstruct里手动注册回调 - 监听器内必须加可重入锁（如
ReentrantLock），防止同一配置多次变更导致并发调用setCorePoolSize() - 禁止在 Spring Bean 初始化阶段（如
afterPropertiesSet）硬编码设置线程池参数；应等配置中心客户端 ready 后再绑定监听
setCorePoolSize() 不是赋值，而是带约束的状态迁移
corePoolSize 是 final 字段，setCorePoolSize(int) 并非直接写值，而是触发 JDK 内部的状态校验与工作线程调度逻辑：
- 若新值 getActiveCount()，方法静默返回，不会中断正在运行的任务线程；只会在后续空闲时自然回收
- 若新值 > 当前
getPoolSize()，也不会立刻创建新线程——只有新任务提交且当前线程数 - 想让扩容“立刻可见”，需配合
prestartAllCoreThreads()（它会无视活跃数，强制拉起 corePoolSize 个空闲线程） - 每次调用后必须校验：
threadPool.getCorePoolSize() == expected，不能只信返回值
动态队列容量需额外封装，原生队列不支持热调
LinkedBlockingQueue、ArrayBlockingQueue 等 JDK 原生队列的容量是构造时固定的，setCapacity() 无意义。要实现队列大小热更新，必须自定义可变容量队列：
- 继承
LinkedBlockingQueue，重写remainingCapacity()和offer()，用volatile int capacity控制上限 - 或采用
ResizableCapacityLinkedBlockingQueue（社区成熟实现），其setCapacity(int)方法会原子更新容量并通知阻塞线程 - 线程池初始化时，必须传入该自定义队列实例，且确保所有线程池操作都走同一个实例引用
- 队列扩容/缩容后，需检查
queue.size()是否超限；若缩容后已超限，应拒绝新任务或触发告警
监控与兜底必须前置，不能等出事才补救
热更新不是“设了就完事”，而是持续可观测的运维闭环：
- 暴露
/actuator/threadpool端点，返回core/max/pool/active/queue.size/queue.remaining等实时指标 - 配置变更后 10 秒内自动采样：对比
getCorePoolSize()、getActiveCount()、getPoolSize()，记录是否生效及偏差原因 - 为每个线程池配置独立的熔断开关（如
threadpool.），异常时可一键降级为单线程同步执行.enabled=true - 所有
setXXX()调用必须打 debug 日志，包含旧值、新值、调用堆栈、是否成功，便于回溯
