
spring 的 `@retryable` 注解默认不会生效,必须在配置类上显式启用 `@enableretry`,否则代理不被创建,重试逻辑完全不会触发。
要使 @Retryable 正常工作,仅添加注解是不够的——Spring Retry 是一个可选模块,其 AOP 代理机制需通过 @EnableRetry 显式激活。否则,即使方法上标注了 @Retryable,调用时也不会触发重试,而是直接执行原始逻辑(即“静默失效”),这正是你遇到的问题:超时异常抛出后无重试、无日志、外部服务无调用痕迹。
✅ 正确启用方式
在任意 @Configuration 类上添加 @EnableRetry:
@Configuration
@EnableRetry
public class RetryConfig {
// 可选:自定义 RetryTemplate 或相关 Bean
}⚠️ 注意:@EnableRetry 必须作用于被 Spring 容器管理的配置类(即被 @Configuration 标记),且该类需被组件扫描加载(如位于主启动类同包或子包下)。
? 修复你的当前实现
你当前将 @Retryable 声明在接口 RetryService 上,这是不推荐且不可靠的做法。Spring Retry 的 @Retryable 仅支持在具体 Bean 的 public 方法上使用(不支持接口方法),因为 JDK 动态代理无法为接口方法织入重试逻辑(CGLIB 代理虽可代理类,但仍要求目标方法在具体类中)。
请按以下方式重构:
1. 移除接口上的 @Retryable,改为在实现类的具体方法上标注:
@Service
public class RetryImpl implements RetryService {
@Override
@Retryable(
value = { ProcessingException.class, SocketTimeoutException.class }, // 明确指定重试异常
maxAttempts = 4,
backoff = @Backoff(delay = 1000, multiplier = 2) // 支持指数退避
)
public T run(Supplier supplier) {
return supplier.get();
}
// 可选:定义 fallback 方法(当所有重试失败后执行)
@Recover
public T recover(Exception e, Supplier supplier) {
log.warn("All retry attempts failed for operation: {}", e.getMessage(), e);
throw new RuntimeException("Operation failed after retries", e);
}
} 2. 确保异常类型可被捕获
你遇到的 javax.ws.rs.ProcessingException 是顶层异常,其 cause 是 SocketTimeoutException。@Retryable 默认只匹配声明的异常类型及其子类,不自动展开 cause。因此,需显式包含:
- ProcessingException.class(直接异常)
- SocketTimeoutException.class(根本原因,也可单独加)
或者更稳妥地,使用 include 属性并配合 @Recover 处理兜底逻辑。
3. 验证代理是否生效
启动应用后,检查日志中是否出现类似:
Creating shared instance of singleton bean 'retryImpl' ... proxy ... created for bean 'retryImpl'
若无此类日志,说明 @EnableRetry 未生效或 RetryImpl 未被 Spring 管理(如缺少 @Service 或扫描路径错误)。
? 补充建议
- 避免在 Lambda 中隐藏异常:supplier.get() 抛出的异常若被内部吞掉,重试将失效。确保 MyClient.cancel() 抛出的异常能透传至 @Retryable 方法。
- 考虑使用 RestTemplate/WebClient + RetryTemplate:对于 HTTP 调用,Spring Retry 与 WebClient 结合(配合 Resilience4j 或原生 RetrySpec)更直观可控。
- 监控与可观测性:添加 RetryListener 或集成 Micrometer,记录重试次数、延迟、失败原因,便于排查“看似休眠”的网络问题(如连接池耗尽、Keep-Alive 超时等)。
✅ 总结
| 问题根源 | 解决方案 |
|---|---|
| 缺少 @EnableRetry | 在 @Configuration 类上添加该注解 |
| @Retryable 标在接口方法 | 改为标注在 @Service 实现类的 public 方法上 |
| 未指定要重试的异常类型 | 显式设置 value = {ProcessingException.class, SocketTimeoutException.class} |
| 异常被静默捕获或包装 | 确保异常链完整传递,必要时自定义 RetryPolicy |
完成上述调整后,当 myClient.cancel(...) 抛出 SocketTimeoutException 时,run() 方法将自动重试最多 4 次,每次间隔 1s(首延迟),并支持指数退避,真正实现容错调用。









