java线程池拒绝策略需按业务场景定制：支付任务拒接时告警+落库重试，日志上报直接丢弃并监控，实时推荐返回默认分，异步通知转存可靠队列；须实现rejectedexecutionhandler接口，注意在调用线程执行且避免耗时操作。
Java 线程池拒绝策略不能只套用内置的四种（AbortPolicy、CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy），关键是要结合业务对任务重要性、失败容忍度、系统稳定性、可观测性的判断来定制。
明确业务场景再决定拒绝时该做什么
不同场景下，“拒绝”不是终点，而是需要差异化响应的信号：
- 支付下单类任务：任务不可丢，失败需强通知。拒绝时应记录告警、落库待重试、触发人工介入流程。
- 日志上报或埋点采集：可容忍丢失，但不能拖垮主流程。拒绝时直接丢弃 + 上报监控指标（如“丢弃埋点数”），不阻塞调用方。
- 实时推荐打分：延迟敏感，允许降级。拒绝时快速返回默认分或缓存结果，并记录降级日志供后续分析。
- 异步邮件/短信发送：最终一致性要求高。拒绝时转存到可靠队列（如 Kafka/RocketMQ），由下游消费者保底执行。
自定义拒绝策略必须实现 RejectedExecutionHandler 接口
核心是重写 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法。注意两点：
- 该方法在调用线程中执行（即 submit() 或 execute() 的线程），不是在线程池线程里 —— 所以避免耗时操作（如远程调用、复杂计算）；
- 参数
r是被拒绝的任务，executor是当前线程池实例，可通过它获取活跃线程数、队列大小、拒绝原因等上下文。
示例：一个带告警和降级返回的拒绝策略
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
public class AlertAndFallbackPolicy implements RejectedExecutionHandler {
private final String bizTag;
private final Supplier<object> fallbackSupplier;
public AlertAndFallbackPolicy(String bizTag, Supplier<object> fallbackSupplier) {
this.bizTag = bizTag;
this.fallbackSupplier = fallbackSupplier;
}
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
// 1. 上报监控（如 Micrometer 计数器）
Metrics.counter("threadpool.rejected", "biz", bizTag).increment();
// 2. 异步发告警（避免阻塞，用独立线程池或消息队列）
AlertClient.asyncAlert("线程池拒绝任务", Map.of(
"biz", bizTag,
"queueSize", executor.getQueue().size(),
"activeCount", executor.getActiveCount(),
"poolSize", executor.getPoolSize()
));
// 3. 若 r 是 Callable 且支持返回值，可尝试同步执行降级逻辑（仅限轻量）
if (r instanceof FutureTask) {
try {
Object fallback = fallbackSupplier.get();
// 将 fallback 结果注入 FutureTask（需反射或封装支持）
} catch (Exception ignored) {}
}
}
}
</object></object>
拒绝策略要配合线程池配置才有意义
单靠策略无法解决问题，必须和以下配置联动：
-
队列类型选对：无界队列（
LinkedBlockingQueue）会让拒绝策略失效（除非手动设置容量），高并发下易 OOM；优先选有界队列（如ArrayBlockingQueue）并设合理容量。 -
核心/最大线程数合理：不要盲目调大 maxPoolSize，要考虑 CPU 密集型 or I/O 密集型，结合
keepAliveTime控制资源回收节奏。 -
监控必须到位：暴露
getQueue().size()、getActiveCount()、getCompletedTaskCount()等指标，拒绝次数突增是容量瓶颈的第一信号。
进阶：拒绝后自动扩容或动态调参（谨慎使用）
在部分云原生或弹性场景下，可让拒绝策略触发轻量级自适应行为：
- 记录最近 1 分钟拒绝次数，超过阈值则通过
setCorePoolSize()和setMaximumPoolSize()微调（注意线程创建开销）； - 拒绝时触发配置刷新，加载新的线程池参数（需配合 Nacos/Apollo 等）；
- 将拒绝事件发布为 Spring Event，由监听器执行清理、告警、补偿等复合动作。
注意：这类动态行为要加锁或限频，防止雪崩式调整；生产环境建议先灰度验证。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
