discardoldestpolicy无法静默淘汰长尾任务，因其仅在队列满时被动丢弃队首待执行任务，不感知执行时长、不扫描队列、不主动清理中间或靠后已超时任务。
discardoldestpolicy 本身不适用于“静默淘汰长尾任务”这个目标——它只在任务提交时触发，且仅丢弃队列头部（即最早入队、尚未执行）的任务，无法识别或干预“正在排队中但耗时过长”的长尾任务。
它真正的作用场景：防提交阻塞
当线程池已满（核心+最大线程都在忙），且工作队列也满了，新任务提交进来时，DiscardOldestPolicy 会立即移除队列里最老的那个待执行任务（不管它等了多久、是否算长尾），腾出一个位置接纳新任务。整个过程无异常、不打日志、不回调，所以叫“静默”。但它不关心任务执行时长，也不感知“长尾”。
为什么它不能解决长尾问题
- 长尾任务通常指已入队、等待时间远超预期，但还没轮到执行的任务——DiscardOldestPolicy 不扫描队列、不设超时、不主动清理；
- 它只在“提交失败临界点”那一瞬间起作用，属于被动防御，不是主动治理；
- 如果长尾任务已经排在队列中间或靠后，它不会被触碰；哪怕它已等了 5 分钟，只要没到队首，就安全。
想静默清理长尾任务？得换思路
你需要的是带超时感知的队列治理机制，例如：
- 用 DelayQueue + 定时巡检：把任务包装成 Delayed 对象，设置逻辑过期时间（如入队后 30s）；另起轻量线程定期 poll 过期任务并丢弃；
- 自定义 BlockingQueue 实现：重写 offer/put 方法，在入队时记录 timestamp；提供 cleanupStaleTasks(long maxAgeMs) 方法由外部按需调用；
- 结合 ScheduledExecutorService：每提交一个任务，同时调度一个“超时检查任务”，到期未开始执行则显式 remove（需队列为 LinkedBlockingQueue 等支持 remove(object) 的类型）；
- 改用 SynchronousQueue + 拒绝策略兜底：避免堆积，让上游承担重试或降级逻辑，从源头减少长尾生成可能。
如果仍想用 DiscardOldestPolicy，注意这些细节
- 仅对 ArrayBlockingQueue 和 LinkedBlockingQueue 有效（它们有明确的“队首”概念）；
- 对 SynchronousQueue 或 PriorityBlockingQueue 行为不可靠或无意义；
- 务必确保队列容量合理——太小导致频繁丢弃，太大掩盖长尾问题；建议配合监控（如 queue.size()、task wait time histogram）及时发现异常堆积。
