ThreadPoolExecutor四种内置拒绝策略应按场景选用：AbortPolicy适合可重试的快速失败场景；CallerRunsPolicy适用于不能丢任务且对吞吐敏感的后台作业；DiscardPolicy仅用于无影响的采样任务；DiscardOldestPolicy可能破坏公平性，需谨慎使用。
ThreadPoolExecutor 的四种内置拒绝策略怎么选
线程池任务被拒绝，不是配置错了，而是队列满 + 线程数已达 maximumPoolSize，此时必须由拒绝策略决定如何处理新提交的 Runnable。JDK 提供的四种策略行为差异极大，选错会导致静默丢任务、阻塞提交线程、甚至 OOM。
实际用得最多的是 AbortPolicy（默认）和 CallerRunsPolicy，但它们适用场景完全不同：
-
AbortPolicy：直接抛RejectedExecutionException，适合能快速失败、上游可重试的场景（如 RPC 客户端异步回调） -
CallerRunsPolicy：让submit()所在线程自己执行该任务，会降低提交速率，适合对吞吐敏感但不能丢任务的后台作业（如日志聚合） -
DiscardPolicy：静默丢弃，无日志无提示，极易掩盖问题，仅建议在“丢了也不影响业务”的采样类任务中使用 -
DiscardOldestPolicy：丢掉队列头任务，再尝试重新提交当前任务；注意——它不保证公平性，且可能反复挤掉同一任务
自定义拒绝策略必须实现 RejectedExecutionHandler 接口
内置策略不够用？比如需要记录被拒任务的堆栈、上报监控、写入死信队列——就得自己写。核心就一条：实现 RejectedExecutionHandler.rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法。
关键注意事项：
立即学习“Java免费学习笔记（深入）”；
- 该方法在提交线程中同步执行，**不能阻塞或耗时过长**，否则会拖慢所有
execute()调用 - 不要在 handler 里再调用
executor.execute(r)，极大概率引发无限递归或死锁 - 如果要落盘或发消息，务必用独立线程池或异步方式，例如交给
CompletableFuture.runAsync(..., asyncLoggerPool)
public class LoggingRejectedHandler implements RejectedExecutionHandler {
private final Logger logger = LoggerFactory.getLogger(LoggingRejectedHandler.class);
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
logger.warn("Task rejected: {}, pool: {}, queue size: {}",
r.getClass().getSimpleName(),
executor.getPoolSize(),
executor.getQueue().size());
// 注意：这里不执行 r.run()，也不调用 executor.execute(r)
}
}
execute() 和 submit() 触发拒绝策略的时机完全一致
有人误以为 submit() 返回 Future 就会“排队更优先”，其实不会。无论是 execute(r) 还是 submit(r) 或 submit(callable)，底层都走同一个任务接纳流程：addWorker() → 队列 offer → 拒绝判断。只要线程池状态满足拒绝条件，就会触发策略。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
区别只在于：
-
execute()：拒绝时直接抛异常，调用方必须捕获RejectedExecutionException -
submit()：拒绝时同样抛RejectedExecutionException，但异常发生在返回Future之前，所以你根本拿不到那个Future
也就是说，Future.isDone() 或 get() 不会遇到“被拒”状态——任务压根没进池子。
饱和时队列类型会影响拒绝发生的频率
用 LinkedBlockingQueue（无界队列）看似安全，实则危险：当核心线程全忙，所有新任务全进队列，内存可能被撑爆，直到 OutOfMemoryError。而 ArrayBlockingQueue（有界）会在队列满时更快触发拒绝，把压力显性暴露出来。
常见误配：
-
corePoolSize=2, maxPoolSize=10, queue=new LinkedBlockingQueue(1000)→ 实际并发能力≈2，其余 998 个任务全排队，响应延迟不可控 -
corePoolSize=2, maxPoolSize=10, queue=new ArrayBlockingQueue(100)→ 达到 102 个待处理任务时就开始拒绝，倒逼你优化或扩容
真正合理的配置，是让队列长度 × 平均任务耗时 ≈ 可接受的最大排队延迟，再结合拒绝策略做兜底。这个平衡点，没法靠拍脑袋定。
