java线程池拒绝策略需自定义rejectedexecutionhandler实现日志与报警，记录任务、线程池上下文及堆栈，结合限频报警和监控指标提升可观测性，避免耗时操作与无限递归。
Java 线程池的任务拒绝策略本身不自带日志或报警能力，需通过自定义 RejectedExecutionHandler 实现日志记录与报警逻辑。
实现自定义拒绝策略并记录日志
继承或实现 RejectedExecutionHandler 接口，在 rejectedExecution 方法中添加日志输出。推荐使用 SLF4J 或 Log4j2 等成熟日志框架，避免直接调用 System.out。
- 获取被拒绝的
Runnable任务，可尝试转为具体类型（如FutureTask）提取业务标识 - 记录线程池名称、当前队列大小、活跃线程数、核心/最大线程数等上下文信息
- 建议记录堆栈（
Thread.currentThread().getStackTrace()），便于定位提交方
集成报警机制（轻量级）
在拒绝处理逻辑中触发报警，注意控制频率，避免雪崩式告警。
- 使用计数器 + 时间窗口（如 Guava 的
RateLimiter或简单时间戳判断）限制单位时间内报警次数 - 报警方式可选：发送企业微信/钉钉机器人消息、写入监控系统（如 Prometheus + AlertManager）、发邮件（建议异步，避免阻塞拒绝处理）
- 报警内容应包含关键指标：拒绝时间、线程池名、拒绝原因（如
CallerRunsPolicy还是AbortPolicy）、最近 5 分钟拒绝次数趋势（如有监控埋点）
结合监控指标提升可观测性
仅靠拒绝时报警不够，需前置感知风险。
- 定期采集线程池指标：如
getActiveCount()、getQueue().size()、getCompletedTaskCount()，上报至监控平台 - 设置阈值告警：队列使用率 > 80%、活跃线程数持续等于最大线程数、拒绝数突增等
- 将线程池实例注册为 Spring Bean 时，可通过
@ManagedResource暴露 JMX 接口，方便运维实时查看
避免常见陷阱
自定义拒绝策略看似简单，但容易引入新问题。
- 拒绝处理逻辑必须快——不能执行耗时操作（如同步远程调用、大对象序列化），否则会拖慢线程池整体拒绝流程
- 不要在拒绝处理器里重新提交任务（除非明确设计为降级重试），易导致无限递归或资源耗尽
- 若使用异步报警（如发消息），需考虑失败重试与丢失容忍；关键业务建议落库+补偿任务兜底
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
