DiscardOldestPolicy 的核心作用是当线程池饱和时丢弃队列中等待最久的任务为新任务腾位置，本质是牺牲旧任务保新任务；必须搭配有界队列使用，不适用于无界队列或优先级队列。
DiscardOldestPolicy 的核心作用是：当线程池无法接纳新任务（即 队列已满 + 线程数已达 maximumPoolSize）时，主动丢弃队列中等待时间最长的那个任务，再尝试把当前新任务加进队列。它不是“优先执行最新任务”，而是“为最新任务腾位置”，本质是一种牺牲旧任务保新任务的取舍逻辑。
适用场景：新任务时效性远高于旧任务
典型例子包括：
- 实时行情推送：每秒产生数百条价格更新，只关心最新几秒的数据，过期行情无业务价值
- 设备心跳包处理：客户端每 10 秒上报一次状态，只需处理最近一次，中间丢失可接受
- 前端埋点采样：用户行为流中，最新交互比 30 秒前的操作更值得分析
关键前提：必须搭配有界队列使用
DiscardOldestPolicy 只在队列满时才触发丢弃动作。若用 LinkedBlockingQueue（默认容量 Integer.MAX_VALUE），队列几乎永远不会满，该策略形同虚设。
正确做法是显式指定有界队列，例如：
new ThreadPoolExecutor(2, 4, 60L, TimeUnit.SECONDS,new ArrayBlockingQueue<Runnable>(100), // 明确容量 100
new ThreadPoolExecutor.DiscardOldestPolicy());
注意 FIFO 队列下的实际丢弃行为
在标准 ArrayBlockingQueue 或 LinkedBlockingQueue（FIFO）中，DiscardOldestPolicy 确实丢弃队列头（最先进入、等待最久）的任务。但需警惕两点：
- 如果队列中已有大量低优先级任务，而新任务是高优指令，丢弃最旧任务不等于丢弃低优任务——可能刚丢的是一个关键任务，而高优任务仍卡在队尾
- 在持续高压下（如每秒提交 200 个任务，线程池吞吐仅 50），会出现“抖动”：新任务刚入队就被下一个新任务顶掉，导致某些任务反复被挤出，永远无法执行
增强可控性的建议操作
- 监控丢弃率：通过自定义包装器或 AOP，在 rejectedExecution 方法里打点统计，一旦丢弃率 > 1%，立即告警
- 配合提交限流：在调用
execute()前，用令牌桶或滑动窗口控制单位时间提交量，避免队列长期饱和 - 慎用于优先级队列：若用
PriorityBlockingQueue，DiscardOldestPolicy 可能丢弃的不是“最旧”，而是“优先级最低”的任务（取决于具体实现），行为不可控，不推荐
