DiscardOldestPolicy 是线程池拒绝策略，当有界队列满且线程全忙时丢弃队列头最老的 Runnable 并尝试加入新任务，并非丢弃超时任务；需显式配置有界队列才生效。
DiscardOldestPolicy 是什么，它真能“丢弃过期任务”？
不是。它不丢弃“过期”的任务（比如超时未执行的任务），而是当线程池饱和（工作队列已满 + 所有线程忙碌）时，**丢弃等待队列头部那个最老的 Runnable，然后尝试把新任务加入队列**。名字里的 “oldest” 指的是队列里排队时间最长的那个，不是按任务自身 deadline 判断的。
常见错误现象：RejectedExecutionException 没出现，但发现某些任务“神秘消失”，且消失的往往是最早提交却迟迟没被执行的那个——这正是 DiscardOldestPolicy 在起作用。
- 只在
execute()被调用且触发拒绝策略时生效；submit()也会走同一套拒绝流程 - 它不关心任务是否实现了
Delayed或带超时逻辑，纯看队列 FIFO 顺序 - 如果队列是无界（如
LinkedBlockingQueue），永远不触发该策略——因为永远不会“满”
怎么正确配置并启用 DiscardOldestPolicy
必须显式传入，线程池默认策略是 AbortPolicy（直接抛异常）。关键点在于：**策略生效的前提是使用有界队列**。
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, 4,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<Runnable>(10), // 必须是有界队列
new ThreadPoolExecutor.DiscardOldestPolicy() // 显式指定
);-
ArrayBlockingQueue、PriorityBlockingQueue（注意：它的“有界”需手动设 capacity）可用；LinkedBlockingQueue无参构造是无界的，慎用 - 别把
DiscardOldestPolicy和CallerRunsPolicy混用——后者让调用线程自己执行任务，行为完全不同 - 策略对象是无状态的，可复用；不需要每次 new 一个
DiscardOldestPolicy 的实际副作用和坑
它看似“温和”，但可能引发隐蔽问题：被丢弃的任务如果持有资源（如打开的文件句柄、数据库连接）、或依赖前置状态，就容易出错。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 丢弃动作发生在
offer()失败后，但此时新任务还没进队列，老任务已被移除——**没有回调、不通知、不保证原子性** - 若队列是
PriorityBlockingQueue，头部不一定是“时间最早”的任务（取决于compareTo()实现），DiscardOldestPolicy仍会丢 head，结果可能不符合预期 - 高并发下反复触发该策略，说明线程池容量或队列大小严重不匹配负载，这时“丢任务”只是掩盖问题，不是解决方案
替代方案比 DiscardOldestPolicy 更合适的情况
如果你真正想要的是“丢弃已过期的任务”，而不是“丢弃队列里最老的”，那 DiscardOldestPolicy 就不是对症药。
- 用
ScheduledThreadPoolExecutor+scheduleWithFixedDelay()控制节奏，比靠拒绝策略更可控 - 任务自身检查时间戳：在
run()开头判断System.nanoTime() - submitTime > timeoutNs，直接 return - 需要严格保序或不能丢任务？换用
CallerRunsPolicy或自定义策略记录日志+告警
真正难的不是选哪个策略，而是确认你到底想丢什么——是“排太久的”，还是“等太急的”。名字误导性太强，用之前一定得看清楚源码里 discardOldest() 到底删了谁。
