java线程池拒绝策略是系统过载时的关键防线，支付类核心链路首选abortpolicy并捕获异常落库或发死信；日志类适用discardpolicy但需监控告警；实时任务推荐discardoldestpolicy；生产环境建议自定义策略，具备记录、降级、限频能力。
Java线程池拒绝策略不是配置项里的“装饰品”，而是系统过载时的最后一道业务防线。选错策略，轻则任务静默丢失、接口偶发500，重则核心交易中断、监控失焦。关键不在“能不能用”，而在“这个场景下，它该做什么”。
支付类核心链路：必须感知失败，不能丢也不能拖
订单支付、资金划转等操作要求强一致性，任务绝不能被静默丢弃，也不宜让Web容器线程（如Tomcat线程）直接执行——否则会阻塞请求处理线程，引发雪崩。
- 首选 AbortPolicy，配合上层统一异常捕获
- Controller 或 Service 层捕获
RejectedExecutionException，立即落库或发消息到死信队列，触发异步重试 - 禁用
CallerRunsPolicy：避免反压到HTTP线程，导致整个服务响应变慢甚至超时 - 避免仅靠加大队列缓解：堆积任务会吃光堆内存，GC频繁，反而加剧不可用
日志/埋点等非关键采集：可丢弃，但需可观测
用户行为日志、性能指标上报等任务丢失单条不影响主流程，但大量丢失说明系统已严重过载，需被快速发现。
- 适用 DiscardPolicy：零开销丢弃，不抛异常、不阻塞提交线程
- 必须配套监控：统计每分钟拒绝数，超阈值触发告警（如1分钟内拒100+次）
- 建议加轻量日志：只记次数和时间戳，不记任务内容（避免IO拖慢submit）
- 慎用
DiscardOldestPolicy：老日志可能含关键上下文（如会话起始事件），丢弃可能破坏分析完整性
实时监控与告警推送：保新不保旧，优先响应最新状态
设备心跳上报、实时风控规则匹配、告警通知发送等场景，最新数据价值远高于历史积压数据。
- 推荐 DiscardOldestPolicy：主动腾出队列空间，确保新任务能尽快入队
- 适合短周期、高频率、时效敏感型任务
- 注意搭配合理队列类型：如使用
ArrayBlockingQueue，需预估峰值吞吐，避免因扩容失败反复触发拒绝 - 避免与
CallerRunsPolicy混用：监控类任务通常无状态、轻量，无需调用方兜底执行
生产环境强烈建议自定义策略：记录+降级+限频
默认 AbortPolicy 在Web服务中极易导致未捕获异常冒泡至容器，返回500；而 DiscardPolicy 则完全无声无息。真实可用的策略应具备三要素：可追溯、有兜底、不扰民。
- 实现
RejectedExecutionHandler接口，记录关键上下文：任务类名、当前活跃线程数、队列长度、时间戳 - 同步执行轻量降级逻辑：如返回缓存值、空响应、或调用本地fallback方法（严禁发HTTP、查DB等耗时操作）
- 内置滑动窗口计数器（如
AtomicInteger+ 定时重置），超阈值仅发一次告警，避免告警风暴 - 禁止在拒绝逻辑中做线程池自身依赖的操作（如再往同一线程池 submit），防止死锁或递归拒绝
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
