maximumPoolSize是线程池最大线程数，用于应对突发流量的弹性缓冲带；设小导致任务拒绝率高，设大引发上下文切换与OOM；需按IO/CPU密集型任务特征、QPS与耗时估算，并配合监控、动态配置及合理拒绝策略。
maximumPoolSize 是线程池中允许存在的最大线程数量，它直接决定了线程池在突发流量下能并行处理多少个任务。这个值不是越大越好，也不是越小越安全，而是一个需要结合系统资源、任务特征与业务容忍度综合权衡的边界参数。
它管的是“临时撑住”的那部分并发
当核心线程都在忙、工作队列也满了，新来的任务就会触发创建新线程，直到线程总数达到 maximumPoolSize。超过这个数的任务，才会被拒绝策略处理（如抛异常、丢弃或调用者自己执行）。所以它本质是应对短时脉冲的“弹性缓冲带”。
- 设得太小：突发流量一来，大量任务被拒绝，接口报错率飙升
- 设得太大：线程过多引发上下文切换开销剧增、内存占用暴涨，甚至触发 OOM 或系统卡顿
- 合理值通常 ≈ （预估峰值 QPS × 平均任务耗时）÷ CPU 核心数 × 调整系数（1.2~1.5）
和任务类型强相关：IO 密集型可适当放宽
如果是数据库查询、HTTP 调用等 IO 密集型任务，线程常处于等待状态，CPU 利用率低，此时可以设置更高的 maximumPoolSize 来提升吞吐；但如果是图像压缩、加解密等 CPU 密集型任务，线程数接近 CPU 核心数就已足够，再多只会拖慢整体响应。
- IO 密集型建议：corePoolSize × 2 ~ × 4，上限看内存和连接池容量
- CPU 密集型建议：CPU 核心数 + 1 ～ + 2 即可，重点压测 CPU 使用率
- 混合型任务需按占比拆解，优先保障关键路径的线程资源
必须配合监控和动态调节机制
静态配置容易过时。线上真实流量模式会变，依赖固定值容易导致“平时富余、大促崩盘”或“常年饥饿、资源浪费”。建议：
- 暴露线程池指标：活跃线程数、队列长度、拒绝数、平均任务耗时
- 设置告警：当活跃线程持续 > 90% maximumPoolSize 或拒绝率 > 0.1%，立即预警
- 接入动态配置中心（如 Nacos、Apollo），支持运行时调整，避免重启生效
别忘了拒绝策略才是最后防线
maximumPoolSize 不是万能兜底。当它也被打满，拒绝策略（RejectedExecutionHandler）才真正决定系统行为。默认的 AbortPolicy 直接抛异常，适合强一致性场景；CallerRunsPolicy 让调用线程自己执行，可自然降速；DiscardPolicy 或 DiscardOldestPolicy 更适合异步日志类任务。
- 选哪种策略，取决于任务是否可丢失、是否可延迟、是否允许调用方阻塞
- 自定义拒绝逻辑也很常见：记录日志+发告警+写入死信队列重试
- 拒绝数上升 ≠ 一定要调大 maximumPoolSize，先查是不是下游慢、缓存失效或 SQL 慢查
不复杂但容易忽略：maximumPoolSize 的价值不在“设多大”，而在“为什么是这个数”——背后要有数据支撑、有场景验证、有兜底手段。
