动态修改核心线程数需明确setcorepoolsize()仅重定义后续创建规则：调大不立即建线，调小不中断运行线程；须配合prestartallcorethreads()预热、allowcorethreadtimeout(true)缩容回收，并接入配置中心、设置校验与监控告警。
动态修改核心线程数是生产环境应对流量波动、避免重启的关键能力，但直接调用 setCorePoolSize() 很容易“调了等于没调”——因为它的行为不直观，且受队列状态、空闲线程回收机制等多重因素影响。实战中必须配合触发策略、可观测性与兜底机制，才能真正落地。
明确 setCorePoolSize() 的真实行为边界
它不是“立即扩容/缩容指令”，而是“后续创建规则的重定义”：
- 调大时：不会立刻新建线程，只在有新任务提交、且当前活跃线程无法及时消费队列积压时，才逐步创建新核心线程
- 调小时：不会中断运行中线程，只将超出部分标记为“可回收”；需等待空闲超时（keepAliveTime）后才退出
- 若希望调大后马上生效：必须额外调用
prestartAllCoreThreads()主动预热 - 若希望调小后尽快回收：需提前设置
allowCoreThreadTimeOut(true)，否则空闲核心线程永不退出
构建可落地的动态调优流程
不能靠人工临时登录服务器改参数，而要嵌入标准运维链路：
- 接入配置中心（如 Nacos / Apollo），监听指定 key（如
threadpool.order.core-size）变更事件 - 封装安全的调整方法，校验新值合法性（不能 > maximumPoolSize，不能
- 调整后自动触发
prestartAllCoreThreads()（仅对调大场景）或记录待回收线程数（对调小场景） - 同步更新监控指标标签（如 Prometheus 的
core_pool_size{pool="order"}），确保调参前后可比
必须配套的监控与熔断信号
没有监控的动态调参等于盲调。重点关注三个联动指标：
- activeCount ≈ corePoolSize 且 queue.size 持续 > 70% remainingCapacity → 表明线程已饱和、队列开始堆积，是扩容信号
- activeCount 长期 0.98 → 说明线程严重闲置，可考虑缩容
- rejected.count 突增 或 activeCount 短时冲高后回落缓慢 → 可能是下游抖动导致任务阻塞，此时盲目扩容会加剧资源争抢，应先查拒绝原因而非调参
规避高频踩坑点
这些细节决定动态调参是否稳定可靠：
- 不要在无界队列（如
LinkedBlockingQueue未设容量）上依赖setCorePoolSize—— 因为任务永远优先入队，几乎不触发新线程创建 - RocketMQ / Dubbo 等框架内嵌线程池，需先通过 Bean 名称或自定义注册方式拿到真实实例，再调用
setCorePoolSize - 缩容后若发现线程数迟迟不降，检查是否遗漏
allowCoreThreadTimeOut(true)，这是最常被忽略的开关 - 批量任务类线程池（如定时导出）建议与实时请求类隔离，避免互相干扰调参逻辑
