Spring @Async架构处理定时长耗时API调用的问题咨询

场景背景 #

Spring应用每分钟检查新任务，并行执行子任务；子任务依赖外部API（令牌有效期1小时，需续期），运行时长10分钟至数小时；所有子任务完成后转换并保存结果。

当前实现：

• 用Scheduler每分钟触发@Async函数，通过CompletableFuture编排子任务：

CompletableFuture<Result> subtask1 = subtaskService1.performTask()
             .thenCompose(subtaskService1::transform);

CompletableFuture<Result> subtask2 = subtaskService2.performTask()
             .thenCompose(subtaskService2::transform);

CompletableFuture<Result> subtask3 = subtaskService3.performTask()
             .thenCompose(subtaskService3::transform);


CompletableFuture.allOf(subtask1, subtask2, subtask3).join();

saveResult(subtask1.get(), subtask2.get(), subtask3.get());

• performTask标注@Async，逻辑：
  1. 令牌无效/过期时获取新令牌；
  2. 启动远程流程；
  3. while循环+Thread.sleep(2分钟)轮询任务状态；
  4. 返回结果用CompletableFuture.supplyAsync()或completedFuture()。

问题1：WebClient获取令牌时出现"block()/blockFirst()/blockLast() are blocking error" #

原因 #

WebClient的filter链处于响应式调用栈中，同步调用block()会阻塞响应式NIO线程，违反非阻塞原则，触发框架保护机制。

解决方案 #

将令牌获取改为非阻塞响应式逻辑，用flatMap替代同步block：

// 替换原有withBearerAuth中的同步令牌获取逻辑
private Mono<ClientResponse> withBearerAuth(ClientRequest request) {
    return tokenProvider.getValidToken() // 改为返回Mono<String>的非阻塞方法
            .map(token -> ClientRequest.from(request)
                    .headers(headers -> headers.setBearerAuth(token))
                    .build())
            .flatMap(next::exchange);
}

// 令牌提供者的非阻塞实现
public Mono<String> getValidToken() {
    return Mono.defer(() -> {
        if (tokenValid()) {
            return Mono.just(currentToken);
        }
        // 用WebClient异步获取新令牌，禁止block
        return authWebClient.post()
                .uri("/oauth/token")
                .bodyValue(authRequest)
                .retrieve()
                .bodyToMono(TokenResponse.class)
                .doOnNext(resp -> {
                    currentToken = resp.getAccessToken();
                    expireTime = System.currentTimeMillis() + resp.getExpiresIn() * 1000;
                })
                .map(TokenResponse::getAccessToken);
    });
}

同时用原子类或线程安全容器存储令牌与过期时间，保证线程安全。

问题2：线程池标识混乱（Spring Async池/ForkJoinPool/parallel-x） #

差异说明 #

• Spring Async线程池：标注@Async的方法默认使用Spring配置的线程池，线程前缀由配置决定，属于受控的业务线程池。
• ForkJoinPool.commonPool：CompletableFuture.supplyAsync()默认使用JDK全局共享的ForkJoinPool.commonPool()，Stream的parallel()也会复用该池。
• parallel-x：自定义ForkJoinPool或第三方库独立ForkJoinPool会生成此类线程标识。

是否异常？ #

属于非预期但不致命的情况，但会导致线程池管理失控（比如commonPool并行度由CPU核心数决定，无法通过Spring配置调整），建议统一线程池。

解决方案 #

1. 给CompletableFuture.supplyAsync()指定Spring异步线程池：

@Autowired
private TaskExecutor asyncTaskExecutor;

// 在supplyAsync时显式指定线程池
CompletableFuture.supplyAsync(() -> {
    // 任务逻辑
}, asyncTaskExecutor);

2. 所有@Async方法通过@Async("customExecutor")指定统一自定义线程池，避免默认池混用。

问题3：线程池并行度未达预期（CorePoolSize=10但3个子任务无法并行） #

原因 #

1. Thread.sleep阻塞线程：子任务轮询时的Thread.sleep(2分钟)会长时间占用Spring Async线程池的线程，导致新任务无法获取资源。
2. 线程池配置不合理：若queueCapacity过大，线程池不会扩容到maxPoolSize；或allowCoreThreadTimeOut未开启，核心线程被占用后无法释放。
3. 任务调度冲突：Scheduler每分钟触发的任务与未完成的旧任务抢占线程池资源。

解决方案 #

1. 将阻塞轮询改为非阻塞延迟，释放线程池资源：

// 替换while+sleep的轮询逻辑
private Mono<RemoteResult> pollRemoteTaskStatus(String taskId) {
    return Mono.defer(() -> remoteApiClient.getTaskStatus(taskId))
            .flatMap(status -> {
                if (status.isCompleted()) {
                    return remoteApiClient.getTaskResult(taskId);
                }
                // 非阻塞延迟2分钟后重试
                return Mono.delay(Duration.ofMinutes(2))
                        .then(pollRemoteTaskStatus(taskId));
            });
}

2. 调整线程池配置适配长任务：

@Bean(name = "longTaskExecutor")
public TaskExecutor longTaskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(10);
    executor.setMaxPoolSize(20);
    executor.setQueueCapacity(0); // 无队列，直接扩容到maxPoolSize
    executor.setThreadNamePrefix("long-task-");
    executor.setAllowCoreThreadTimeOut(true);
    executor.initialize();
    return executor;
}

3. 给长耗时的performTask指定专用长任务线程池，避免与短任务混用。

问题4：是否应使用Virtual Threads（虚拟线程）？ #

适用场景 #

虚拟线程适合大量阻塞等待的IO密集型任务，你的子任务包含长时间API等待、轮询睡眠，这类场景下虚拟线程可大幅降低系统资源占用，避免物理线程耗尽。

建议 #

可以逐步引入，具体方案：

1. Spring Boot 3.2+支持直接配置虚拟线程作为异步线程池：

@Bean(name = "virtualThreadExecutor")
public Executor virtualThreadExecutor() {
    return Executors.newVirtualThreadPerTaskExecutor();
}

2. 给@Async方法指定虚拟线程池：@Async("virtualThreadExecutor")
3. 保留Thread.sleep(Duration.ofMinutes(2))即可，虚拟线程的睡眠不会占用物理线程。

注意事项 #

• 虚拟线程不适合CPU密集型任务，你的场景以IO等待为主，匹配度极高。
• Spring生态对虚拟线程支持良好，无需担心第三方库兼容性问题。
• 无需手动管理虚拟线程生命周期，JVM会自动调度。

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