掌握线程池关键在理解参数背后的资源权衡与行为逻辑：七参数协同决定任务流转路径（核心线程→队列→非核心线程→拒绝），拒绝策略是服务降级决策点而非简单兜底，需结合业务容忍度选型，参数设置应依CPU/IO密集特征估算并动态调优。
掌握线程池参数与拒绝策略，关键不在死记硬背，而在理解每个配置背后的资源权衡和系统行为逻辑。面试官真正想听的，是你能讲清“为什么这么设”“不这么设会怎样”“线上出问题怎么定位”。下面从四个实战维度帮你打通任督二脉。
搞懂七参数不是背名字，是理清任务流转路径
ThreadPoolExecutor 的七个参数是一个协同工作的整体，核心执行顺序是：先用核心线程 → 队列排队 → 再扩非核心线程 → 最后触发拒绝。很多人误以为“队列满就拒绝”，其实队列满后还会尝试创建新线程（只要未达 maximumPoolSize）。重点要讲清三组联动：
- corePoolSize 和 workQueue：二者共同决定“稳态承载能力”。比如核心线程数为 4、队列为 100 的池子，意味着系统可稳定处理 4 个并发，其余 100 个任务可缓冲等待；若队列太大（如用 LinkedBlockingQueue 不设限），可能掩盖线程不足问题，最终内存溢出。
- maximumPoolSize 和 keepAliveTime + unit：控制弹性边界。非核心线程只在队列满且任务持续涌入时才创建，空闲超时即销毁。设得太小（如 max=core）等于关闭扩容能力；设得太大（如 max=1000）又可能压垮 CPU 或引发上下文切换风暴。
- workQueue 类型决定行为分水岭：ArrayBlockingQueue（有界）会较早触发扩容或拒绝；SynchronousQueue（容量为 0）相当于“直传模式”，任务直接交由空闲线程，没空闲就立即扩容；DelayedWorkQueue 专用于 ScheduledThreadPool。选错队列，参数再准也白搭。
拒绝策略不是兜底选项，而是服务降级的决策点
四种内置策略对应四类业务容忍度，不能只说“AbortPolicy 抛异常”，而要说明它适合什么场景：
- AbortPolicy（默认）：适用于强一致性、不允许丢失或延迟的任务，比如支付扣款回调。抛 RejectedExecutionException，上游需捕获并重试或告警。
- CallerRunsPolicy：让提交任务的线程自己执行，可自然减缓生产者速度。适合下游处理能力波动大、允许短暂同步阻塞的场景，如日志聚合批量写入。
- DiscardPolicy：静默丢弃，零开销。适合实时性要求高但可丢失的指标采集类任务。
- DiscardOldestPolicy：丢掉队列头任务，腾位置给新任务。适合消息队列消费端等“保最新不保全量”的场景。
进阶要点：生产环境建议自定义拒绝策略，记录被拒任务的 traceId、参数摘要、堆栈，方便事后追溯是否是突发流量、bug 循环提交，还是配置长期不合理。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
参数设置不能拍脑袋，得结合业务特征算
没有万能公式，但有可落地的估算锚点：
- CPU 密集型任务：线程数 ≈ CPU 核数 × (1 + 平均等待时间 / 平均工作时间)，通常取 core = max = CPU 核数 + 1，避免过多线程争抢 CPU。
- IO 密集型任务（如 DB 查询、HTTP 调用）：线程常阻塞在等待响应上，可适当放大。常见经验值是 core = 2 × CPU 核数，max 可设为 core 的 1.5~2 倍，队列大小按平均 QPS × 平均响应时间 × 安全系数（如 2~3）估算。
- 混合型或不确定型：优先保守——宁可稍慢，不可雪崩。推荐 core = 8～16，max = core × 2，队列 = 100～500，上线后通过监控（活跃线程数、队列长度、拒绝数）动态调优。
面试加分项：能讲清源码关键路径和排查思路
提到 execute() 方法，可简述其主干逻辑：
- 如果当前线程数
- 否则尝试 offer 到 workQueue；成功则任务入队等待；
- offer 失败（如队列满），再 try to addWorker 创建非核心线程；
- 若 addWorker 失败（已达 maximumPoolSize 或线程池已 shutdown），走 reject()。
线上排查三板斧：
- 看 jstack 输出中 pool 名称和线程状态，确认是否大量线程 BLOCKED 在队列 take() 或 RUNNABLE 却无进展；
- 查 GC 日志和堆内存使用趋势，判断是否因无界队列导致 OOM；
- 监控 RejectedExecutionException 出现频率和时间点，关联业务流量图，确认是突增流量、下游变慢拉长队列，还是线程池长期配置偏低。
