java线程池自定义拒绝策略需实现rejectedexecutionhandler接口，核心在于合理设计兜底逻辑：必须确保队列有界且线程达上限才触发；避免递归提交、补偿操作须超时降级、日志限流；按业务选择不丢任务（发mq重试）、可观测丢弃（打点监控）或调用方感知（抛异常）。
先确认触发条件是否真实存在
拒绝策略只在两个条件**同时满足**时触发：工作队列已满（且为**有界队列**，如 ArrayBlockingQueue(100)），当前线程数已达 maximumPoolSize。若用的是无界队列（如默认 LinkedBlockingQueue），任务会无限堆积，OOM 风险远高于触发拒绝策略——此时策略形同虚设。
-
使用
ArrayBlockingQueue 或 SynchronousQueue 替代无界队列；
设置合理的队列容量，例如按峰值 QPS × 平均处理时长 × 安全系数估算；
监控 executor.getQueue().size() 和 executor.getActiveCount()，而非只盯拒绝数。
避免常见实现陷阱
很多自定义策略看似能跑通，上线后却引发雪崩或丢任务。以下三点必须规避：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
不在
rejectedExecution 方法里调用 executor.submit() 或 execute()，否则可能递归触发拒绝，甚至死锁；
补偿操作（如发 MQ、写 DB）必须带超时与降级：MQ 发送失败时，应 fallback 到本地磁盘暂存（按时间戳命名 JSON 文件），而非直接吞异常；
日志要限流：高频拒绝时，logger.warn("rejected: {}", taskId) 可接受，但 e.printStackTrace() 会打爆 I/O。
按业务语义选择补偿方向
拒绝不是失败终点，而是任务生命周期的转折点。策略设计要匹配下游能力：
-
要求不丢任务 → 封装成可序列化对象（如
SerializableTask），含参数快照、traceId、重试次数，发往 Kafka/RocketMQ 延迟重试队列；
允许丢弃但需可观测 → 在丢弃前记录关键字段（如任务 ID、类型、提交时间），并打点到监控系统（如 metrics.counter("rejected", "type", "pay_callback").increment()）；
需调用方感知 → 包装异常信息返回（如抛出 TaskRejectedException 并附带 traceId），由上层做熔断或降级（如返回兜底数据）。
一个轻量可靠的落地示例
以“落 MQ + 本地降级”为例，不依赖 Spring 或复杂框架：
-
定义任务包装类：
TaskEnvelope 实现 Serializable，仅存 JSON 参数、时间戳、唯一 ID；
拒绝处理器中：构造 TaskEnvelope → 尝试同步发 RocketMQ（设置 1s 超时、最多 2 次重试）→ 失败则写入 /data/reject/20260806_152341.json；
单独起一个守护线程，定时扫描该目录，成功发送后删除文件，失败则告警。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
