java线程池有4种内置拒绝策略：1. abortpolicy抛异常，适用于支付等关键业务；2. callerrunspolicy由调用线程执行，实现降速，适合非实时任务；3. discardpolicy静默丢弃，用于可丢失任务；4. discardoldestpolicy丢弃最老任务，适用于新数据价值更高的场景。
Java线程池常见的拒绝策略有4种，全部内置在 ThreadPoolExecutor 中，实现 RejectedExecutionHandler 接口。它们在任务无法入队、也无法扩容线程时被触发，行为和适用场景差异明显。
AbortPolicy：直接抛异常（默认策略）
当线程池已满（线程数达 maximumPoolSize 且工作队列已满），新任务会被拒绝，并立即抛出 RejectedExecutionException。
- 不丢任务也不执行，只通知调用方失败
- 适合关键业务，比如支付、订单创建——必须让上层感知失败并做补偿或重试
- 系统监控可捕获该异常，快速告警定位瓶颈
CallerRunsPolicy：由提交线程自己执行
拒绝发生时，不丢任务、不抛异常，而是让调用 execute() 的线程（比如主线程）同步执行该任务。
- 本质是“降速”机制：调用线程被占用，自然减缓后续任务提交节奏
- 能避免任务丢失，但可能拖慢调用方逻辑（如 Web 请求线程阻塞）
- 适合非实时核心任务，如日志落盘、异步通知、后台统计等
DiscardPolicy：静默丢弃新任务
新任务直接被忽略，既不执行也不抛异常，控制台无任何输出。
立即学习“Java免费学习笔记（深入）”；
- 零开销，对调用方完全透明
- 风险在于“悄无声息丢数据”，需确保任务可丢失
- 常用于监控埋点、用户行为统计等弱一致性场景
DiscardOldestPolicy：丢掉队列里最老的任务，再尝试提交新任务
先从工作队列头部移除一个等待最久的任务（FIFO 队列中即最早入队的），然后重新尝试将当前任务加入队列。
- 优先保障新任务处理，牺牲旧任务时效性
- 要求队列支持
poll()操作（如ArrayBlockingQueue、LinkedBlockingQueue） - 适用于行情推送、实时告警等“新数据价值远高于旧数据”的场景
选哪种策略，关键看三件事：任务能不能丢、要不要立刻知道失败、是否允许调用线程变慢。实际项目中，也常结合自定义策略——比如记录拒绝日志 + 上报 Prometheus 指标 + 触发限流开关。
