大促并发峰值靠“感知—判断—响应—收敛”闭环稳住，而非堆线程；扩容需基于队列堆积率＞75%且持续3周期、活跃线程达上限且有拒绝、平均等待超200ms三指标联动触发。

大促期间的并发峰值不是靠“堆线程”扛过去的，而是靠“感知—判断—响应—收敛”的闭环机制稳住的。关键不在于最大能开多少线程，而在于什么时候该扩、扩多少、扩完怎么收、收完是否留痕可溯。

一、扩容触发必须基于多维实时指标

单看队列长度或CPU使用率都容易误判。真正可靠的触发条件是三者联动：

• 队列堆积率 > 75%：不是绝对数量，而是当前队列大小 ÷ 队列容量；持续3个采样周期（如每5秒一次）超阈值才触发
• 活跃线程数 == 最大线程数 且 拒绝任务数 > 0：说明已到硬瓶颈，必须扩容或降级
• 平均任务等待时长 > 200ms：比响应时间更早暴露排队问题，是扩容的黄金前置信号

二、扩容不是线性加法，而是带约束的梯度演进

盲目翻倍会引发上下文切换风暴。推荐采用“保底+弹性”双层策略：

• 保底扩容：核心线程数从64 → 128（适用于QPS从5k突增至15k的典型大促开场）
• 弹性上限：最大线程数按公式动态计算：newMax = min(500, currentMax × (1 + queueSize / queueCapacity × 0.3))
• 每次扩容后强制休眠200ms，避免连续抖动；同一分钟内最多触发2次扩容

三、扩容必须配套队列与拒绝策略协同

只调线程数，不调队列和拒绝策略，等于给油门配了手刹：

• 队列改用 有界 LinkedBlockingQueue，初始容量设为预估峰值QPS × 平均处理时间（如15k × 0.15s ≈ 2250），并启用动态扩容接口
• 拒绝策略切为 CallerRunsPolicy（流量突增初期）→ 自定义熔断策略（持续高负载，直接返回“活动暂未开启”）
• 当最大线程数已达上限且队列仍满，自动启用“轻量级降级开关”：跳过非必要日志、监控打点、异步通知

四、扩容不是终点，回收与复位才是稳定性保障

大促结束后的“线程滞留”比峰值本身更危险：

• 设置 keepAliveTime = 30s，配合 allowCoreThreadTimeOut(true)，让所有线程（含核心）在空闲后可释放
• 启动后台定时任务，每30秒检查：活跃线程数 ，则逐步将核心线程数回调至日常值（如从128→64→32）
• 所有调整操作写入审计日志，并同步推送至配置中心，确保重启后参数可恢复