DiscardPolicy在线程池饱和且队列满时静默丢弃任务，不抛异常、不记录日志；需满足RUNNING状态、有界队列、execute()提交等条件，其rejectedExecution方法为空实现。
Java 线程池使用 DiscardPolicy 时，会直接丢弃新提交但无法执行的任务，且不抛异常、不记录日志、不通知调用者——真正“安静”。关键在于正确配置线程池并理解其触发时机。
什么时候会触发 DiscardPolicy？
只有当线程池已饱和（核心线程 + 非核心线程全忙）且工作队列也满时，新任务才会被拒绝。此时拒绝策略生效。
- 线程池状态为 RUNNING（非 SHUTDOWN 或 TERMINATED）
- 队列是有限容量的（如
ArrayBlockingQueue），不能是无界队列（如LinkedBlockingQueue默认容量 Integer.MAX_VALUE） - 任务提交方式为
execute()；若用submit()，同样走拒绝流程，但返回的Future在 get() 时会抛出RejectedExecutionException
如何显式指定 DiscardPolicy？
通过 ThreadPoolExecutor 构造器或 setRejectedExecutionHandler() 设置：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, // corePoolSize
4, // maxPoolSize
60L, // keepAliveTime
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(10), // 有界队列，容量 10
new ThreadPoolExecutor.DiscardPolicy() // 显式指定
);
也可复用已有实例：executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy());
立即学习“Java免费学习笔记（深入）”；
DiscardPolicy 的行为细节
它内部只有一行实现：public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { } —— 空方法。
- 不会打印日志，不会中断线程，也不会修改任务状态
- 调用方完全感知不到任务被丢弃（除非自行监控任务提交量与执行量的差值）
- 适合对任务丢失容忍度高、吞吐优先、且能接受“尽力而为”的场景（如实时日志采集、埋点上报）
需要警惕的常见误区
很多人以为只要设了 DiscardPolicy 就万事大吉，其实容易踩坑：
-
用了无界队列：比如
new LinkedBlockingQueue()，队列永远不会满，拒绝策略永不触发 -
线程池已 shutdown：此时即使队列未满，也会走拒绝流程，
DiscardPolicy同样静默丢弃 -
误以为 submit() 更安全：其实
submit()包装后仍是execute()提交，一样被丢弃；只是后续 get() 才暴露异常
