线程池拒绝策略是系统真正过载时的最后一道防线，需同时满足活跃线程达maximumpoolsize且工作队列已满才触发；应按任务重要性分层选用策略，核心任务用abortpolicy或带告警补偿的自定义策略，非核心任务可选discardoldestpolicy或discardpolicy，callerrunspolicy仅适用于轻量本地操作；自定义策略须轻量、异步、可观测；更关键的是前置流控，如入口限速、慢依赖熔断、任务拆分与水位监控。
线程池拒绝策略不是用来“扛流量”的，而是系统真正过载时的最后一道业务防线。它不解决任务太多的问题，只决定多出来的任务怎么收场。要实现优雅处理，关键在于：任务不丢核心逻辑、上游不被拖垮、问题可追溯可干预。
先确认是不是真过载
很多所谓“线程池满了”，其实是任务在队列里堆积，还没触发拒绝逻辑。尤其用 LinkedBlockingQueue 且没设容量上限时，队列能撑到内存耗尽，根本不会走拒绝流程。真实过载需同时满足：
- 活跃线程数已达 maximumPoolSize（调用
getActiveCount()判断） - 工作队列已满（如 ArrayBlockingQueue 达到构造时设定的容量，查
getQueue().size()）
只有这两个条件都成立，新任务提交才会进入拒绝策略执行路径。
按任务重要性分层选策略
不能把所有任务塞进同一个线程池，更不能混用策略。必须先识别业务中的“核心变量逻辑”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 必须保住的：支付扣款、库存预占、风控决策、订单创建主链路——这些任务失败会直接引发资损或客诉
- 可降级的：日志上报、异步通知、埋点统计、非实时推荐
对应策略选择：
- 核心任务 → 用 AbortPolicy 或带告警+补偿的自定义策略，确保异常显式暴露，触发熔断或人工介入
- 非核心但需保量的任务 → 可考虑 DiscardOldestPolicy（保新不保旧），适合心跳上报、实时风控等时效敏感场景
- 纯采集类任务（如监控指标）→ DiscardPolicy 静默丢弃，但必须配套每分钟拒绝数监控，超阈值立即告警
- CallerRunsPolicy 不是兜底万能键：仅适用于调用线程本身轻量可控的任务（如本地缓存更新），严禁用于含远程调用、DB 查询或 HTTP 请求的任务，否则会卡死 Tomcat/Netty 工作线程
自定义策略必须做到三件事
生产环境强烈建议自定义 RejectedExecutionHandler，默认策略在 Web 场景中极易导致未捕获异常冒泡返回 500，或静默丢失无感知：
- 轻量：拒绝逻辑必须快，禁止同步打聚合日志、发告警、操作共享集合，否则会阻塞后续所有任务提交
- 异步：告警、指标上报、消息落库等重操作，必须扔进独立线程池或消息队列，与拒绝路径解耦
-
可观测：至少记录
traceId、任务类型（如"sms-notify"）、线程池名（如"notify-tp"）、当前队列大小、活跃线程数；建议用AtomicLong统计拒绝次数，并通过 Micrometer 暴露为 Prometheus 指标
比换策略更重要的事
拒绝策略再好也只是事后补救。可持续的流控必须前置：
- 在入口用 RateLimiter 或 Semaphore 主动限速，比等线程池背压更可控
- 对慢依赖（如远程调用、DB 查询）加超时和熔断，避免单个慢任务拖垮整个池
- 拆分大任务，减少单任务执行时间，提升线程周转率
- 基于实际
getQueue().size()和getActiveCount()做水位监控，当队列持续 > 80% 容量时提前告警，而不是等拒绝大量发生才响应
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
