17370845950

Java线程池有4种内置拒绝策略：1. AbortPolicy抛异常，适用于支付等关键业务；2. CallerRunsPolicy由调用线程执行，实现降速，适合非实时任务；3. DiscardPolicy静默丢弃，用于可丢失任务；4. DiscardOldestPolicy丢弃最老任务，适用于新数据价值更高的场景。

Java线程池常见的拒绝策略有4种，全部内置在 ThreadPoolExecutor 中，实现 RejectedExecutionHandler 接口。它们在任务无法入队、也无法扩容线程时被触发，行为和适用场景差异明显。

AbortPolicy：直接抛异常（默认策略）

当线程池已满（线程数达 maximumPoolSize 且工作队列已满），新任务会被拒绝，并立即抛出 RejectedExecutionException。

• 不丢任务也不执行，只通知调用方失败
• 适合关键业务，比如支付、订单创建——必须让上层感知失败并做补偿或重试
• 系统监控可捕获该异常，快速告警定位瓶颈

CallerRunsPolicy：由提交线程自己执行

拒绝发生时，不丢任务、不抛异常，而是让调用 execute() 的线程（比如主线程）同步执行该任务。

• 本质是“降速”机制：调用线程被占用，自然减缓后续任务提交节奏
• 能避免任务丢失，但可能拖慢调用方逻辑（如 Web 请求线程阻塞）
• 适合非实时核心任务，如日志落盘、异步通知、后台统计等

DiscardPolicy：静默丢弃新任务

新任务直接被忽略，既不执行也不抛异常，控制台无任何输出。

• 零开销，对调用方完全透明
• 风险在于“悄无声息丢数据”，需确保任务可丢失
• 常用于监控埋点、用户行为统计等弱一致性场景

DiscardOldestPolicy：丢掉队列里最老的任务，再尝试提交新任务

先从工作队列头部移除一个等待最久的任务（FIFO 队列中即最早入队的），然后重新尝试将当前任务加入队列。

• 优先保障新任务处理，牺牲旧任务时效性
• 要求队列支持 poll() 操作（如 ArrayBlockingQueue、LinkedBlockingQueue）
• 适用于行情推送、实时告警等“新数据价值远高于旧数据”的场景

选哪种策略，关键看三件事：任务能不能丢、要不要立刻知道失败、是否允许调用线程变慢。实际项目中，也常结合自定义策略——比如记录拒绝日志 + 上报 Prometheus 指标 + 触发限流开关。