setmaximumpoolsize仅影响后续线程创建决策，不终止/回收/唤醒已有线程；生效需满足任务数≥corepoolsize且工作队列已满；须同步调整workqueue（改用有界队列）、corepoolsize（设为均值1.5～2倍）和keepalivetime（可降至10～20秒）。

理解 setMaximumPoolSize 的真实作用边界

很多人误以为调用 setMaximumPoolSize() 就能“立刻多开线程”，其实它只影响后续的线程创建决策，不终止、不回收、不唤醒已有线程。它生效的前提是：线程池当前正在执行的任务数 ≥ corePoolSize，且工作队列已满，正处在“准备扩容但还没到 maximum”的临界态。如果队列没满，哪怕流量再大，线程数也不会超过 corePoolSize——这是很多线上扩容失败的根本原因。

必须配套调整的三个关键参数

单独改 maximumPoolSize 几乎无效，需同步检查并按需调整：

• workQueue 类型与容量：若用的是 LinkedBlockingQueue（无界队列），任务永远进队列，never 触发 maximum 扩容。生产环境必须用有界队列（如 ArrayBlockingQueue），并设合理容量（例如 200～500），让队列满后真正“逼出”新线程；
• corePoolSize 是否过低：若 core 是 4，maximum 调到 64，但流量突增时前 4 个线程+队列就扛住了，其余 60 个线程根本不会创建。建议将 core 设为日常均值的 1.5～2 倍，并预留 30%～50% 的 maximum 上浮空间；
• keepAliveTime 是否合理：默认 60 秒，意味着非核心线程空闲超时即销毁。秒级扩容后若流量回落快，线程可能刚建好就销毁，造成反复震荡。可临时降至 10～20 秒，或配合监控动态回调恢复。

安全、可观测的线上热扩操作流程

不写死配置，不重启，靠外部信号触发：

• 暴露一个 HTTP 管理端点（如 /actuator/threadpool/resize），接收 maxSize 和 queueCapacity 参数；
• 在接口内先校验新值合法性（不能小于当前 activeCount，不能超过预设安全上限如 200）；
• 调用 setMaximumPoolSize(newSize)，同时通过反射或自定义队列方式动态调整队列容量（注意：标准 ArrayBlockingQueue 不支持运行时扩容，需封装一层带 resize 能力的代理队列）；
• 立即记录 audit 日志，并推送指标（如 thread_pool_max_size{pool="biz"} 64）到 Prometheus；
• 配套告警：当 getPoolSize() == getMaximumPoolSize() 持续 30 秒，且队列排队数 > 50，触发“线程池打满”预警，提示需进一步干预或降级。

比扩容更关键的兜底手段

线程池不是万能保险丝。真实高并发场景下，应分层防御：

• 前置限流：用 Sentinel 或 Resilience4j 在入口做 QPS 熔断，避免请求洪峰直接打到线程池；
• 异步化拆分：把耗时操作（如日志、通知、统计）剥离到独立线程池或消息队列，主流程线程池只做核心计算；
• 自动降级开关：当线程池活跃度 > 90% 且平均响应时间翻倍时，自动关闭非关键功能（如商品推荐、用户行为埋点）；
• 扩容只是临时止血，事后必须分析 GC 日志、慢 SQL、外部依赖超时等根因——多数“流量飙升”本质是某个下游抖动引发的线程堆积雪崩。