DiscardOldestPolicy的核心逻辑是先移除队列中最老任务再重试提交新任务；适用于最新数据必须优先处理、旧数据价值低的场景，如实时行情推送、IoT心跳聚合、监控采样；禁用于有状态/顺序依赖任务，避免在无界或超大容量队列使用，并需防范雪崩式重试。
DiscardOldestPolicy 的核心逻辑是：当新任务被拒绝时，先从任务队列中移除等待时间最长的那个任务（即“最老任务”），再尝试把当前被拒任务重新加入队列。它不是简单丢弃新任务，而是用“腾位置+重试”的方式争取执行机会。
适用前提：任务有强时效性，且旧数据价值明显低于新数据
这种策略只在“最新数据必须优先处理”且“稍旧数据可舍弃”时才真正合理。典型场景包括：
- 实时行情推送系统：每秒产生上千笔股票快照，消费者处理稍慢就会积压；队列里滞留3秒前的报价已无业务意义，丢掉它让最新报价尽快入队更关键
- IoT设备心跳聚合服务：成千上万设备按秒上报状态，后台按分钟窗口做统计；若队列满，丢掉10秒前的心跳比丢掉刚上报的更有利
- 监控指标采样管道：采集CPU、内存等指标用于告警，延迟超过5秒的样本对实时决策无效，保留最新样本即可
使用时必须注意的三个风险点
这个策略表面“聪明”，实则容易埋坑，需严格约束使用条件：
- 不能用于有状态或依赖顺序的任务：比如订单状态更新任务若被反复挤出又重试，可能造成状态覆盖或重复提交
- 避免在无界队列或超大容量队列上启用：DiscardOldestPolicy 对 LinkedBlockingQueue（默认无界）无效；即使设了容量，若队列过大（如10万），poll() 操作可能引发锁竞争或GC压力
- 警惕“任务雪崩式重试”：如果线程池持续过载，每次拒绝都丢最老任务再重试当前任务，可能导致同一任务反复被拒绝、反复入队，形成无效循环
搭配建议：加日志 + 限频 + 监控告警
DiscardOldestPolicy 默认不记录任何信息，生产环境务必包装增强：
立即学习“Java免费学习笔记（深入）”；
- 自定义包装类，在
rejectedExecution中记录被丢弃任务的类型、提交时间、队列当前长度等上下文 - 对丢弃行为做限频，比如每分钟最多记录10条丢弃日志，避免日志刷爆磁盘
- 将丢弃次数接入监控大盘，设置阈值告警（例如5分钟内丢弃超100次，触发扩容或降级检查）
对比其他策略：为什么不用 DiscardPolicy？
DiscardPolicy 是直接丢新任务，适合完全可丢、无时效要求的场景（如抽样日志）。而 DiscardOldestPolicy 本质是“用旧换新”，适用于你明确知道：宁可丢失历史片段，也不能错过最新信号。它比 DiscardPolicy 更激进，也更需要业务语义支撑。
