可安全修改但需配套动作：调大需 prestartAllCoreThreads() 预热，调小需 allowCoreThreadTimeOut(true) 才能回收；须接入配置中心、校验参数、记录审计日志，并监控 activeCount、队列水位等指标联动判断。
可以安全修改，但必须理解它的行为边界并配套必要动作——单纯调用 setCorePoolSize() 很可能“改了没用”。
核心线程数修改的真实逻辑
setCorePoolSize() 不是立即扩容/缩容指令，而是重定义后续线程创建与回收规则：
- 调大时：不会立刻新建全部线程，只在有新任务提交、且当前活跃线程无法及时处理队列积压时，才逐步创建新核心线程
- 调小时：不会中断任何运行中线程，只将超出部分标记为“可回收”；需等待空闲超时（keepAliveTime）后才退出
- 若希望调大后马上生效：必须额外调用
prestartAllCoreThreads()主动预热 - 若希望调小后尽快回收：必须提前设置
allowCoreThreadTimeOut(true)，否则空闲核心线程永不退出
生产环境安全调整的必备步骤
不能靠人工登录服务器临时修改，而要嵌入标准运维链路：
- 接入配置中心（如 Nacos / Apollo），监听指定 key（如
threadpool.order.core-size）变更事件 - 封装带校验的调整方法：确保新值 ≤ maximumPoolSize，且 ≥ 1；非法值直接拒绝
- 调大时自动触发
prestartAllCoreThreads()；调小时记录待回收线程数，并同步更新监控指标标签（如 Prometheus 的core_pool_size{pool="order"}） - 所有调整操作需记录审计日志，包含操作人、旧值、新值、时间戳
必须配套的监控与判断依据
没有监控的动态调参等于盲调。重点关注三个联动指标：
-
activeCount ≈ corePoolSize且queue.size > 70% remainingCapacity→ 表明线程已饱和、队列开始堆积，是扩容信号 -
activeCount长期 corePoolSize 且pool utilization → 说明线程严重闲置，可考虑缩容 -
rejected.count突增 或activeCount短时冲高后回落缓慢 → 可能是下游抖动导致任务阻塞，此时盲目扩容会加剧资源争抢，应先查拒绝原因
高频踩坑点提醒
这些细节决定动态调参是否真正落地：
- 不要在无界队列（如未设容量的
LinkedBlockingQueue）上依赖setCorePoolSize——因为任务永远优先入队，几乎不触发新线程创建 - RocketMQ / Dubbo 等框架内嵌线程池，需先通过 Bean 名称或自定义注册方式拿到真实实例，再调用
setCorePoolSize - 缩容后线程数迟迟不降？第一反应检查是否遗漏
allowCoreThreadTimeOut(true)，这是最常被忽略的开关 - 避免高频反复调整：两次修改间隔建议 ≥ 5 分钟，防止线程频繁启停带来 GC 压力和上下文切换开销
