setCorePoolSize()可动态调整核心线程数，但需满足未shutdown且新值≥当前活跃线程数，否则静默失败；调大时按需创建线程，调小时空闲线程超时回收。
直接调用 getCorePoolSize() 无法实现动态变更——它只是读取当前值，不修改任何配置。真正用于“促销压测中动态提升并发能力”的，是 setCorePoolSize(int) 方法，配合合理策略和监控闭环。
压测前：明确目标与安全边界
促销压测不是盲目加线程，而是验证系统在更高并发下的稳定性与响应能力。需提前确定：
-
基准线：记录日常流量下
getCorePoolSize()、getActiveCount()、队列积压量、平均任务耗时 - 安全上限：根据 CPU 密集型（建议 ≤ CPU 核心数 + 1）或 I/O 密集型（可设为 2–4 倍 CPU 核心数）预估最大合理值，避免上下文切换反拖慢性能
-
拒绝策略兜底：压测期间必须启用
CallerRunsPolicy或自定义日志化拒绝策略，防止任务静默丢失
压测中：分阶段调用 setCorePoolSize 并验证生效
不能一次性跳到目标值，需逐步调整并观察反馈：
- 先检查状态：
if (!executor.isShutdown() && newVal >= executor.getActiveCount())，否则setCorePoolSize(newVal)会静默失败 - 每次调增后立即校验：
executor.getCorePoolSize()确认值已更新，executor.getPoolSize()和executor.getActiveCount()观察是否开始扩容 - 若线程数未增长，说明当前无新任务触发创建——可提交一个轻量 dummy 任务，或调用
executor.prestartAllCoreThreads()强制拉起（注意：该方法在 shutdown 后返回 0，需前置判断）
压测后：自动回滚与指标归因
促销结束不能依赖人工恢复，应设计自动降配逻辑：
- 监听 Nacos/Apollo 配置变更事件，在“压测开关关闭”时触发
setCorePoolSize(原基础值) - 降配前再次校验：
getActiveCount() ≤ 新 core 值，避免中断正在执行的任务 - 同步采集关键指标对比：压测前后相同 QPS 下的 P95 延迟、队列堆积率、GC 次数、CPU 使用率，归因性能瓶颈是否在线程池本身
配套监控不可少
仅靠参数调整无法闭环，必须暴露并采集以下指标：
-
getActiveCount()：真实并发负载，高于getCorePoolSize()说明已启用非核心线程 -
getQueue().size()：持续 > 70% 容量，说明核心线程+队列已成瓶颈 -
getCompletedTaskCount()与getTaskCount()差值：反映积压任务量 - JVM 线程数（
java.lang:type=Threading）：确认 OS 层线程是否真实创建，排除线程工厂异常
