java线程池自定义拒绝策略需实现rejectedexecutionhandler接口，在rejectedexecution方法中注入业务决策逻辑，如降级、重试、告警等；触发条件为线程池未关闭且核心线程、工作队列、最大线程数均已达上限；须校验!executor.isshutdown()，避免重复操作；建议封装带业务属性的自定义任务类，结合日志与监控记录关键字段；支持多层响应组合，如落库+异步转发+告警；需规避内存泄漏、非线程安全、耗时操作及未捕获异常。
Java线程池自定义拒绝策略，核心在于实现 RejectedExecutionHandler 接口，并在 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法中注入业务判断与处置逻辑。它不是简单的“兜底补救”，而是把任务拒绝转化为可控的业务决策点——比如降级、重试、告警、异步补偿或数据落库。
明确拒绝触发时机，避免误判
策略只在特定条件下生效：线程池未关闭，且同时满足——核心线程已满、工作队列已满、最大线程数已达上限。不能假设“只要提交慢就触发”，更不能在策略里反复调用 executor.execute(r) 造成无限递归或死循环。
- 务必先检查
!executor.isShutdown()，防止对已关闭线程池重复操作 - 避免在拒绝逻辑中直接调用
executor.submit()或execute()，除非你明确设计了重试通道（如备用线程池） - 可通过
executor.getPoolSize()、executor.getQueue().size()、executor.getActiveCount()获取实时状态，辅助做分级决策
支持任务上下文提取，不止是“丢还是不丢”
默认的 Runnable 是无状态的，但真实业务任务往往携带 ID、用户标识、订单号等关键信息。建议封装自定义任务类：
- 让任务实现
Runnable同时提供 getter 方法（如getOrderId()、getTimestamp()） - 在拒绝策略中做类型判断：
if (r instanceof OrderTask)，再强转提取字段 - 结合日志或监控埋点，记录被拒任务的业务属性，而非仅打印
r.toString()
按场景组合处理动作，拒绝策略可以“多层响应”
单一动作（如只打日志）往往不够。生产环境常见组合逻辑：
- 同步记录：将任务元数据写入本地文件或 Redis 缓存，供后续人工核查或补偿调度
- 异步转发：将被拒任务序列化后发往 Kafka 或 RocketMQ，由下游消费者重试或降级处理
- 触发告警：调用内部告警 SDK，带上线程池名、队列水位、拒绝数量等维度，避免“静默丢任务”
- 降级执行：若任务非核心（如统计上报），可改为同步轻量执行（如写内存计数器），不依赖线程池
规避常见陷阱，保障策略本身稳定
拒绝策略代码虽短，却极易引入隐患：
- 不用 Lambda 写策略：隐式捕获外部对象（如 Spring Bean、大缓存 Map）会导致内存泄漏，尤其在线程池长期运行时
- 拒绝逻辑必须线程安全：避免在策略中修改共享集合或静态变量，必要时加锁或用并发容器
- 禁止耗时操作：策略执行应控制在毫秒级，否则会阻塞线程池的拒绝判定流程，拖慢整体吞吐
- 不要忽略异常：策略内抛出未捕获异常会导致该次拒绝失败，可能触发上层默认策略，行为不可控
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
