java线程池拒绝策略在核心线程满、任务队列满且线程总数达最大值（或线程池已关闭）时触发，是高并发下任务兜底的关键机制，而非简单配置即可生效的摆设。
Java线程池拒绝策略不是“配了就行”的摆设，而是高并发场景下任务兜底的关键开关。它在核心线程满、队列满、最大线程也满时才真正生效——这个临界点一旦没处理好，轻则丢任务、重则引发级联故障。实战中，必须结合业务语义选策略、加可观测性、留逃生通道。
拒绝策略触发的真实条件
很多人误以为只要队列满了就会拒绝，其实完整链路是：
- 新任务提交 → 当前线程数
- 否则 → 尝试入队；入队失败（队列已满）→ 若当前线程数
- 否则（队列满 + 线程已达 maximumPoolSize）→ 拒绝策略生效
特别注意：SynchronousQueue容量为 0，任务无法排队，会直奔扩容逻辑；若已达 maxPoolSize，立刻拒绝。所以用 cachedThreadPool 时，拒绝来得更快、更突然。
四大内置策略怎么选
每种策略行为明确，但适用场景差异极大：
- AbortPolicy（默认）：抛 RejectedExecutionException。适合强一致性场景，如支付扣款，宁可失败也不容忍状态不一致
- CallerRunsPolicy：由提交线程同步执行任务。本质是反压机制，能自然降速，但慎用于 Web 请求线程或 Netty EventLoop，否则阻塞主线程
- DiscardPolicy：静默丢弃最新任务。适合日志采集、监控埋点等允许丢失的异步辅助任务
- DiscardOldestPolicy：丢弃队列头部最老任务，腾位置给新任务。适合时效性强的任务（如行情推送），但无日志、难追溯
自定义策略要解决三个实际问题
生产环境不能只靠“打印一行日志”，自定义策略需兼顾可观测性、可追溯性和可恢复性：
- 记录上下文：不只是打印“任务被拒”，还要记录 task ID、提交时间、队列大小、活跃线程数（executor.getQueue().size()、executor.getActiveCount()）
- 区分任务类型：通过 instanceof 判断是否为自定义任务类（如 CustomTask），提取业务字段（订单号、用户ID），便于告警和排查
- 提供降级路径：比如写入本地磁盘缓冲区、发到 Kafka 重试队列、或调用降级接口返回默认值（如缓存兜底）
一个生产可用的自定义策略示例
以下策略做到三件事：打结构化日志、提取业务 ID、推送至重试 Topic：
public class KafkaRetryPolicy implements RejectedExecutionHandler {
private final String topic;
private final KafkaProducer<string byte> producer;
public KafkaRetryPolicy(String topic, KafkaProducer<string byte> producer) {
this.topic = topic;
this.producer = producer;
}
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
if (r instanceof CustomTask) {
CustomTask task = (CustomTask) r;
String key = "retry_" + System.currentTimeMillis();
byte[] payload = serialize(task); // 自定义序列化
producer.send(new ProducerRecord(topic, key, payload));
log.warn("Task rejected and sent to retry topic: orderId={}, queueSize={}",
task.getOrderId(), executor.getQueue().size());
}
}
}</string></string>
搭配使用时，务必确保 Kafka 客户端线程安全且有重试/失败回调，避免拒绝策略自身成为新瓶颈。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
