java线程池自定义拒绝策略是保障系统韧性的重要手段，需在rejectedexecutionhandler中实现告警、降级与可观测性，避免阻塞、死锁及非线程安全操作。
Java线程池的拒绝策略不只是“丢任务”那么简单——它是一道关键的安全阀，也是可观测性与弹性设计的入口。当线程池饱和时，合理实现自定义拒绝策略，既能触发监控告警，又能执行业务降级逻辑，避免雪崩。
为什么默认拒绝策略不够用
ThreadPoolExecutor 提供的四种内置拒绝策略（如 AbortPolicy、CallerRunsPolicy）侧重于线程池自身稳定性，但缺乏业务语义：不记录上下文、不通知告警系统、不触发降级兜底。比如支付请求被拒绝，系统应记录失败订单号、推送企业微信告警、返回“稍后重试”而非直接 500。
自定义 RejectedExecutionHandler 实现告警与降级
核心是实现 RejectedExecutionHandler 接口，在 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法中注入监控和降级逻辑：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 提取任务原始信息：若 Runnable 是
FutureTask或封装了业务对象（如PaymentTask），可通过类型判断获取订单ID、用户ID等关键字段 - 同步上报指标：调用 Micrometer 的
Counter.increment()或发送日志到 ELK/SLS，标记“threadpool_reject”事件 - 异步触发告警：通过线程池或消息队列（如 Kafka）将告警事件投递出去，避免阻塞拒绝处理流程
- 执行降级响应：对当前请求线程调用 fallback 方法（如返回缓存结果、空数据、限流提示），注意避免在拒绝处理器中做耗时操作
典型场景下的策略组合建议
不同业务对拒绝的容忍度不同，需按场景定制：
- 高一致性写入场景（如账务流水）：拒绝时记录完整上下文 + 企业微信/钉钉告警 + 抛出特定异常，由上游重试或人工介入
- 读服务（如商品详情）：拒绝时返回本地缓存或兜底静态页，并打点“read_fallback”，不告警但持续监控跌倒率
- 异步任务（如发短信、日志归档）：拒绝时写入死信队列（如 Redis List 或 Kafka DLQ），后续补偿消费，同时记录失败原因
注意事项与避坑点
自定义拒绝策略看似简单，但容易引发新问题：
- 拒绝处理器内不能调用线程池的
execute()或submit()，否则可能死锁或无限递归 - 避免在 handler 中执行 RPC、DB 查询等阻塞操作；告警和降级尽量轻量、异步化
- 确保 handler 实例是线程安全的；若需共享状态（如计数器），使用
AtomicLong或LongAdder - 配合动态配置：通过 Apollo/Nacos 控制是否开启告警、降级开关，便于线上快速熔断
把拒绝当成一次可观测事件来设计，线程池就不再只是并发工具，而是系统韧性的重要支点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
