线程池参数是防止系统雪崩的硬性防线而非性能加分项；核心参数误配（如corepoolsize过小、workqueue无界、maximumpoolsize与队列不匹配）易致资源耗尽；拒绝策略选错会丧失熔断能力；任务混用引发连锁反应；需按特征拆分线程池并监控关键指标。
线程池参数不是性能调优的“加分项”，而是防止系统雪崩的硬性防线。配置失当，一个线程池就能拖垮整个服务。
核心参数直接决定资源是否失控
系统雪崩往往始于资源耗尽——内存撑爆、CPU打满、线程排队超时。这背后几乎都对应着线程池关键参数的误配：
- corePoolSize 过小：CPU密集型任务只配2个核心线程，但服务器有16核，大量计算任务被迫排队，响应延迟飙升
-
workQueue 无界：用
LinkedBlockingQueue不设容量，下游接口慢1秒，每秒涌入500请求 → 队列1分钟积压3万任务 → 堆内存OOM - maximumPoolSize 与队列不匹配：队列容量1000，最大线程数却只设10，任务永远等不到新线程扩容，全卡在队列里
拒绝策略选错等于放弃熔断能力
当线程池饱和，拒绝策略就是最后一道闸门。默认的 AbortPolicy 直接抛异常，调用方若没兜底，就会级联失败；而盲目用 CallerRunsPolicy 在高并发下会让主线程阻塞，Web请求线程被占住，接口直接不可用。
- 对关键业务，建议自定义拒绝策略：记录告警 + 上报监控 + 返回降级响应（如缓存数据或空结果）
- 非关键任务（如日志异步写入）可用
DiscardPolicy，避免低优先级任务拖垮主链路
任务混用让隔离失效，引发连锁反应
把数据库批量导入、PDF生成、HTTP响应处理扔进同一个线程池，本质是让IO阻塞型和CPU密集型任务抢同一组资源。一旦PDF生成卡住5秒，所有线程被占满，新来的HTTP请求全部排队超时，触发下游服务雪崩。
- 按任务特征拆分线程池：HTTP处理池、DB操作池、异步通知池，彼此资源不干扰
- 每个池单独配置参数——比如DB池要匹配连接池大小，避免线程空等连接
没监控的线程池等于盲开高速车
线程池健康不能靠“没报错”判断。必须实时盯紧三个信号：
-
getActiveCount()持续 ≥getPoolSize()→ 线程已打满，任务开始堆积 - 队列长度接近设定上限 → 再涨一点就触发拒绝，需提前干预
- 拒绝任务数突增 → 不是流量上涨，就是下游变慢或线程池配置已到瓶颈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
