拒绝策略缺失等于无防护，会导致队列堆积、线程枯竭、上游雪崩；正确选型需匹配场景，且必须配合有界队列、可观测告警与降级兜底。
不加防线的拒绝策略，本质是把系统压力当作“可忽略的噪音”，任由任务在队列里堆积、线程在阻塞中枯竭，最终让上游服务在毫无预警中被拖垮。它不是最后一道防线失效，而是压根没设防。
拒绝策略缺失 = 放任资源耗尽
线程池没有拒绝策略，就像高速路口撤掉所有红绿灯和限流杆——车流（请求）持续涌入，但出口（线程处理能力）有限。当工作队列填满、最大线程数已达上限，新任务无处安放，系统只能硬扛或崩溃。
- 使用无界队列（如 LinkedBlockingQueue 未设容量）+ 默认 AbortPolicy，看似“能接就接”，实则内存缓慢泄漏，最终触发
OutOfMemoryError: unable to create new native thread - 未显式配置拒绝策略时，ThreadPoolExecutor 默认采用 AbortPolicy，但若上层调用未捕获
RejectedExecutionException，异常会直接中断提交线程，造成请求静默丢失 - 在网关或核心服务中漏配策略，一个下游慢接口就能让整个入口线程池“卡死”，后续所有请求排队超时，形成雪崩起点
四种内置策略的真实代价与适用边界
选错策略不等于没策略，而是用错了“止血方式”：
- AbortPolicy：适合强一致性场景（如支付扣款），但必须配套重试+日志告警，否则异常一抛，业务就断
- CallerRunsPolicy：让调用方自己执行任务，天然降速，适合 Web 容器层（如 Tomcat 接收请求后交由线程池处理），能避免突发流量冲垮下游
- DiscardPolicy：静默丢弃，适用于监控埋点、日志上报等非关键路径；绝不能用于订单创建、库存扣减等主链路
- DiscardOldestPolicy：丢最老任务保最新，适合实时数据流（如传感器上报），但搭配优先级队列可能误删高优任务，需谨慎
真正起作用的拒绝策略，必须带反馈和可观测性
策略本身只是开关，关键在于它是否能联动整个防御体系：
- 配合 有界队列（如
ArrayBlockingQueue(1000)），明确容量边界，避免无限缓冲掩盖问题 - 拒绝发生时，必须记录指标：拒绝数、拒绝率、堆栈快照，并触发告警（如 Prometheus + Alertmanager）
- 在网关层（如 Spring Cloud Gateway）统一配置全局拒绝兜底，而非每个服务各自为政
- 对关键接口做 熔断隔离：即使线程池拒绝了，也要返回降级响应（如默认库存、缓存兜底），而不是抛 500
一个典型雪崩链路还原
某次大促中，商品详情页调用推荐服务，推荐服务又依赖用户画像服务。因画像服务数据库慢查询，响应从 200ms 拉长到 3s。而推荐服务线程池配置为：
core=10, max=20, queue=new LinkedBlockingQueue()（无界）, 拒绝策略未显式设置（即 AbortPolicy）结果：
- 20 个线程全部阻塞在等待画像响应上
- 新请求持续进入无界队列，内存占用飙升
- JVM 频繁 GC，最终 OOM，推荐服务进程退出
- 商品服务因调用超时 + 重试，自身线程池也被打满，连锁崩溃
如果当时配置的是 CallerRunsPolicy + 有界队列（500），商品服务提交请求时就会被“反向压回”，自然降低调用量，给画像服务留出恢复窗口——雪崩被阻断在第二层。
