maximumpoolsize是线程池应对突发流量的弹性缓冲上限，仅在corepoolsize满且workqueue满时触发创建非核心线程，达上限后任务走拒绝策略；需按io/cpu密集型合理设定，并配合动态调节、有界队列与监控压测。
maximumPoolSize 不是“堆多点线程就稳了”的保险丝，而是线程池在突发流量下能临时撑住的并发上限。它真正起作用的时机，是核心线程全忙、工作队列也满了之后——这时新任务才会触发创建非核心线程，直到达到这个数。用错或不管它，轻则接口大量报错，重则系统卡死甚至 OOM。
明确 maximumPoolSize 的真实作用边界
它不是日常承载主力，而是短时脉冲的弹性缓冲带。关键逻辑如下：
- 只有当 corePoolSize 已满 + workQueue 已满 时，才开始创建新线程，且总数不能超过 maximumPoolSize
- 一旦达到该值，后续任务直接走拒绝策略（如抛异常、丢弃、或由调用方自己执行）
- 它不解决“任务积压”本身，只决定“积压到什么程度才开始拒绝”
按任务类型匹配合理取值区间
一刀切设成 200 或 1000 很危险。必须结合任务耗时特征和资源瓶颈来定：
- IO 密集型任务（如 HTTP 调用、DB 查询）：线程常等待，CPU 利用率低 → 可设为 corePoolSize 的 2～4 倍，但上限要受内存和下游连接池容量约束
- CPU 密集型任务（如加解密、图像压缩）：线程基本满负荷跑 → 推荐设为 CPU 核心数 + 1 或 + 2，再多只会加剧上下文切换，拖慢整体响应
- 混合型任务：按 IO/CPU 耗时占比拆解，例如 70% 时间在等 DB、30% 在计算 → 可参考 IO 密集型偏上取值，但需压测验证 CPU 使用率是否突破 80%
避免静态配置失灵，引入动态调节机制
固定写死的 maximumPoolSize 在真实业务中极易失效——大促流量翻倍，平时配置就立刻成为瓶颈；日常低峰又白白占资源。实战建议：
- 把 maximumPoolSize 设为可运行时修改的参数（如通过 Apollo/Nacos 配置中心），支持秒级生效
- 基于实时指标自动调整：当队列堆积率持续 > 80% 或 CPU 负载 > 75%，按梯度上调（如每次 +20%，上限不超过预估峰值 QPS × 平均耗时 ÷ CPU 核数 × 1.5）
- 搭配有界队列（如 ArrayBlockingQueue）使用，防止无界队列让 maximumPoolSize 形同虚设
- 拒绝策略优先选 CallerRunsPolicy 或自定义降级逻辑，而不是默认的 AbortPolicy，避免突发时直接炸开
必须配套监控与压测验证
光调参数没用，得看见效果、发现问题：
- 暴露关键指标：当前活跃线程数、队列长度、拒绝任务数、平均任务耗时
- 压测时重点观察：当 QPS 达到预估峰值时，maximumPoolSize 是否被触达？线程数是否稳定在该值附近？CPU 和 GC 是否陡增？
- 上线后设置告警：拒绝率 > 0.1%、队列堆积 > 90%、线程数长时间打满，都应立即介入
