多AWS EC2实例部署时Spring @Async @Retryable偶发不重试问题

云原生阿岚

2026-8-26

问题触发场景

该问题本质是Spring AOP多注解叠加时代理顺序存在不确定性、异步返回值异常感知存在缺陷，在多实例部署环境下因负载、资源、网络波动放大导致，具体触发场景如下：

AOP代理顺序随机失效：@Async、@Retryable、@Transactional均基于动态代理实现，默认配置下三个注解的代理优先级接近，不同Spring版本、类加载顺序、运行环境下织入顺序可能发生变化。当@Async切面织入在@Retryable外层时，方法调用会立刻被异步线程池提交并返回CompletableFuture实例，@Retryable切面仅能感知方法同步返回时抛出的异常，完全无法捕获异步线程执行过程中、Future内部封装的异常，自然不会触发重试。本地环境线程资源充足、负载低，业务查询异常往往在方法返回Future前就同步抛出，刚好能被Retry感知；多EC2实例部署时流量波动、线程池排队、JIT编译优化都会改变异常抛出时序，偶发异常被封装进Future内部，就会出现重试不触发的问题。
@Retryable默认不支持异步返回值异常解包：原生@Retryable的拦截逻辑仅判断方法调用是否同步抛出异常，不会主动等待CompletableFuture执行完成，也不会解包Future内部的异常完成结果。只要方法正常返回了CompletableFuture对象（哪怕后续这个Future会异常完成），Retry逻辑就会判定方法执行成功，直接返回Future对象，不会触发任何重试。
异步线程池异常吞噬导致Future挂死：多实例部署时如果流量突增，自定义异步线程池队列打满触发拒绝策略，或异步线程抛出未捕获异常，若没有配置对应的异常处理器，线程池会直接吞掉异常，既不会触发重试，也不会将返回的CompletableFuture标记为异常完成，就会出现whenComplete回调永远不触发的现象。EC2实例的CPU、内存配额相比本地开发环境更严格，线程池耗尽、内存溢出、线程中断的概率远高于本地，这类问题出现频率更高。
异常类型漏捕获：配置中仅指定捕获Exception.class，多实例环境下容易出现的OutOfMemoryError、StackOverflowError等JVM错误属于Throwable子类，不在Exception捕获范围内，这类错误抛出时会直接打挂异步线程，既不触发重试也不会正常完成Future。另外跨AZ调用依赖服务的网络闪断、超时异常会被包装为CompletionException，部分低版本Spring Retry无法识别嵌套在包装类内部的业务异常，也会导致重试失效。
实例优雅停机导致任务中断：多EC2实例部署时往往配置了自动扩缩容、滚动发布策略，实例被回收时如果异步任务没有配置等待完成时间，线程会被直接强制中断，CompletableFuture既不返回成功也不抛出异常，直接挂死，回调不会触发，重试逻辑也无法感知。

规避方案

强制指定AOP切面执行顺序：通过注解的order属性显式指定三个注解的织入优先级，order值越小切面越靠外层，固定顺序为@Retryable(order = 0) > @Async(order = 1) > @Transactional(order = 2)，彻底避免不同环境下代理顺序随机的问题。
自定义重试逻辑适配异步返回值：不要依赖默认@Retryable注解处理返回CompletableFuture的方法，自定义RetryTemplate配置支持Future异常解包的重试策略：拿到方法返回的CompletableFuture后，显式等待执行结果，捕获Future内部抛出的异常，符合重试条件时重新提交异步任务。如果追求逻辑可控，可直接在方法内部实现重试逻辑，完全绕开AOP代理对异步返回值的黑盒处理。
规范异步线程池配置：自定义@Async使用的业务线程池，明确设置核心线程数、最大线程数、队列长度，配置带异常传递的拒绝策略（避免用默认的AbortPolicy直接抛出未捕获异常），同时配置线程池的UncaughtExceptionHandler，所有未捕获异常都要将对应的CompletableFuture标记为异常完成，杜绝Future挂死问题。
全链路异常封装+超时控制：所有异步业务逻辑统一通过CompletableFuture.supplyAsync()包装执行，保证所有业务异常都被封装进Future内部，不要在方法体中直接抛出同步异常；给所有CompletableFuture添加orTimeout()全局超时配置，避免任务挂死导致回调不触发，超时异常统一纳入重试判定范围。
扩大异常捕获范围：将@Retryable的捕获范围调整为包含Error类，同时显式声明多实例环境下的常见异常（如线程池拒绝异常、网络超时异常、嵌套事务异常），避免异常漏捕获。
配置优雅停机等待时间：在EC2实例的滚动发布、扩缩容流程中，给异步线程池配置足够的awaitTermination时间，实例回收前等待已提交的异步任务执行完成，避免线程被强制中断导致任务挂死。

修正后的参考代码如下：

// 自定义异步线程池配置示例（需提前注册为Spring Bean）
@Bean("bizAsyncThreadPool")
public ThreadPoolTaskExecutor bizAsyncThreadPool() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(10);
    executor.setMaxPoolSize(20);
    executor.setQueueCapacity(200);
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    executor.setWaitForTasksToCompleteOnShutdown(true);
    executor.setAwaitTerminationSeconds(60);
    executor.initialize();
    return executor;
}

// 修正后的异步方法
@Async("bizAsyncThreadPool")
@Retryable(
    value = {Exception.class, Error.class},
    maxAttempts = 10,
    backoff = @Backoff(delay = 5000),
    order = 0
)
@Transactional(order = 2)
public CompletableFuture<Item> createItemAsync(ItemCode itemCode, Info info) {
    return CompletableFuture.supplyAsync(() -> {
        Item item = itemRepository.findBy(itemCode);
        // 其余业务逻辑
        return item;
    }, bizAsyncThreadPool).orTimeout(25, TimeUnit.SECONDS);
}

涉及异步、重试、事务这类跨切面逻辑时，不要完全依赖Spring注解的默认配置，多实例部署下环境负载、依赖版本、网络状况的微小差异都会放大默认配置的不确定性，显式控制执行顺序、异常传递路径是最可靠的方案。

内容的提问来源于stack exchange，提问作者KhoaVo