Java线程池满载时触发拒绝策略本质是容量告警，AbortPolicy通过抛出RejectedExecutionException将决策权交还业务层，需配合try-catch记录关键指标并降级处理。
Java 线程池在任务满载时触发拒绝策略，本质是系统发出的“容量告警”。处理的关键不是掩盖异常，而是让异常可感知、可追溯、可响应。默认的 AbortPolicy 就是为此设计：它不静默丢弃，也不强行兜底，而是立刻抛出 RejectedExecutionException，把决策权交还给业务层。
明确触发条件，避免误判“满载”
拒绝不是随机发生的，必须同时满足以下条件之一：
- 线程池处于 RUNNING 状态，但当前线程数已达
maximumPoolSize，且工作队列已满（例如ArrayBlockingQueue(2)已无空位） - 线程池已调用
shutdown()或shutdownNow()，不再接受新任务
注意：如果用的是无界队列（如未指定容量的 LinkedBlockingQueue），所谓“满载”往往发生在内存耗尽或 GC 频繁时，此时拒绝策略根本不会触发——这反而更危险，容易掩盖真实瓶颈。
AbortPolicy 必须配合 try-catch 使用
这个异常是 RuntimeException，编译期不强制捕获，但生产环境不捕获等于埋雷：
立即学习“Java免费学习笔记（深入）”；
- 每次调用
execute()或submit()前，都应包裹try-catch - 日志中至少记录：异常堆栈、当前队列大小、活跃线程数、任务简要标识
- 根据业务重要性选择降级动作：写入死信队列重试、返回缓存值、触发人工告警、或（仅限低频轻量任务）同步执行 fallback 方法
慎用 CallerRunsPolicy，尤其在 Web 场景
它让提交线程（比如 Tomcat 的 worker 线程）自己执行被拒任务，看似“不丢任务”，实则风险明显：
- 主线程被阻塞，接口响应时间直线上升，可能引发请求超时或连接池耗尽
- 若任务本身耗时，会形成负向循环：越慢 → 越积压 → 越多线程被拖住 → 更慢
- 只适合任务极轻、执行可控、且允许短暂反压的场景，如本地日志刷盘
自定义策略要轻量、异步、不阻塞
生产环境建议自定义拒绝处理器，但必须守住三条底线：
- 拒绝逻辑内不做耗时操作：不调
submit()、不查数据库、不发 HTTP 请求 - 日志只记关键字段（任务类名、队列 size、pool size），不序列化整个 Runnable
- 告警走异步通道：发 Kafka、推 Prometheus、或写本地 ring buffer，绝不同步等待
真正可持续的方案不在拒绝端，而在源头控流：用 RateLimiter 限速、拆分大任务、优化下游依赖耗时——拒绝策略只是最后一道闸，不是扩容替代品。
