本文介绍一种基于 Supplier 的泛型重试封装方式，通过 @Retryable 注解实现对 JPA Repository 方法（如 findById、findByNumber）的统一重试控制，兼顾类型安全与调用简洁性。
本文介绍一种基于 `supplier
在 Spring 应用中，当数据库连接不稳定时，对 JPA Repository 方法（如 repository.findById("id") 或 repository.findByNumber(311)）进行自动重试是常见需求。直接为每个方法重复添加 @Retryable 不仅冗余，还破坏了泛型抽象能力。理想方案是定义一个通用、类型安全、可复用的重试入口。
推荐采用 Supplier<t></t> 作为函数式参数载体，配合 Spring Retry 的 @Retryable 注解，实现零侵入、强类型的重试封装：
@Service
public class RetryService {
@Retryable(
value = { SQLException.class, RuntimeException.class },
maxAttempts = 3,
backoff = @Backoff(delay = 1000, multiplier = 2)
)
public <T> T executeWithRetry(Supplier<T> operation) {
return operation.get();
}
// 可选：提供带 fallback 的重载方法
@Recover
public <T> T recover(Exception e, Supplier<T> operation) {
log.warn("All retry attempts failed for operation: {}", operation, e);
throw new DataAccessException("Operation failed after retries", e);
}
}使用示例：
@Service
public class EmployeeService {
private final EmployeeRepository repository;
private final RetryService retryService;
public EmployeeService(EmployeeRepository repository, RetryService retryService) {
this.repository = repository;
this.retryService = retryService;
}
public Employee getEmployeeById(String id) {
// ✅ 类型推断自动完成：T = Employee
return retryService.executeWithRetry(() -> repository.findById(id)
.orElseThrow(() -> new EntityNotFoundException("Employee not found: " + id)));
}
public Record getRecordByNumber(int number) {
// ✅ 类型推断自动完成：T = Record
return retryService.executeWithRetry(() -> repository.findByNumber(number));
}
}⚠️ 关键注意事项：
-
AOP 代理限制：
@Retryable基于 Spring AOP 实现，必须通过代理对象调用（即从另一个 Bean 中调用executeWithRetry），不可在本类内直接调用（否则注解失效，等同于普通方法）。这是与@Transactional相同的底层限制。 -
异常触发条件：确保
@Retryable的value属性包含实际可能抛出的异常类型（如SQLException、CannotCreateTransactionException等），默认仅对RuntimeException及其子类重试。 -
返回值语义：
Supplier<t></t>延迟执行，每次重试都会重新调用get()，因此需确保被包装的操作是幂等的（如查询操作天然满足；若含写操作，请谨慎评估业务一致性）。 -
依赖注入要求：
RetryService需启用 Spring Retry 支持（添加@EnableRetry到配置类，并引入spring-retry依赖）。
该方案以最小侵入性达成最大复用性：无需为每个 Repository 方法定义专用接口，不牺牲泛型类型信息，且完全兼容 Spring 的声明式重试生态。
