java线程池拒绝策略不参与dubbo/feign超时重试，而是与之协同实现可控降级、有界重试和可观测补偿；需前置配置合理超时、禁用默认重试、自定义拒绝策略聚焦记录隔离补偿，线程池参数须匹配远程调用特征。
Java线程池拒绝策略本身不直接参与Dubbo或Feign的远程调用超时与重试逻辑，但二者在高并发、下游不稳定场景下会深度耦合——当远程调用因超时堆积任务，导致线程池饱和，拒绝策略才真正被触发。关键不是“用拒绝策略做重试”，而是通过分层设计让拒绝策略与远程调用超时机制协同，实现**可控降级+有界重试+可观测补偿**。
拒绝策略不能替代Feign/Dubbo的重试机制
Feign和Dubbo各自内置了独立的重试能力（如Feign的Retryer、Dubbo的retries配置），它们作用于网络IO层，在请求发出后、响应返回前生效；而线程池拒绝策略发生在任务提交阶段（即execute()调用时），属于执行资源调度层。若把重试逻辑塞进拒绝策略里：
- 可能造成重复提交（Feign已重试3次，拒绝策略又重加一次）
- 无法区分是网络超时、业务异常还是线程池满，重试语义混乱
- CallerRunsPolicy在远程调用场景中极易引发主线程阻塞雪崩
超时设置必须前置且严格收敛
远程调用超时（connect/read timeout）是防止线程池被拖垮的第一道防线。Dubbo和Feign都需显式配置，且应小于线程池的keepAliveTime和队列等待容忍阈值：
- Feign：通过
@RequestLine或全局Request.Options设connectTimeout(3s)、readTimeout(8s) - Dubbo：接口级配置
dubbo.reference.timeout=5000，避免使用默认60s - 务必禁用Dubbo的
retries="3"在核心链路，改用服务端幂等+客户端有限兜底
自定义拒绝策略聚焦“记录+隔离+补偿”，不主动重试
当远程调用超时引发大量任务堆积并最终触发拒绝时，策略目标是保核心、留痕迹、可追溯：
- 记录完整上下文：traceId、method、url、超时耗时、下游服务名、原始参数摘要（脱敏后）
- 按任务类型分级：支付类任务走
AbortPolicy + 告警+人工介入；日志/埋点类走DiscardPolicy静默丢弃 - 补偿路径明确：对必须执行的任务，序列化后写入延迟消息队列（如RocketMQ延时等级30s），由独立消费者重试，而非在线程池内循环提交
- 禁止在
rejectedExecution()中调用Feign/Dubbo客户端——这会形成递归依赖和死锁风险
线程池参数需与远程调用特征匹配
常见错误是线程池大小固定为CPU核数×2，却忽略远程调用的I/O等待特性：
- Feign/Dubbo调用占比高的线程池，
corePoolSize宜设为下游平均RT × QPS × 安全系数（如1.5），而非机器核数 - 队列建议用有界队列（如
ArrayBlockingQueue(200)），避免OOM；拒绝策略统一用自定义实现，不做静默丢弃 - 搭配监控：实时采集
getQueue().size()、getActiveCount()、拒绝计数，水位超70%自动告警并触发限流降级
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
