[Spring] @Async 비동기 동작 원리 파헤치기

목차

- 서론

- @EnableAsync 동작원리

- @Async 동작원리

- 결론

 

실습 환경

- Java 17

- Springboot 3.2.0

 

서론

실무에서 비동기 처리를 위해 CompletableFuture 클래스를 사용했다. 잘 동작하는 것을 확인했지만 문득 @Async 어노테이션을 이용하면 더 편리하지 않을까 하는 생각과 @Async는 어떤 원리로 비동기를 처리하는지 궁금해졌다. @Async 내부 동작을 디버깅 한 결과 결국 @Async 역시 CompletableFuture을 사용하고 있었다.

이 글에서는 스프링부트에서 @Async 어노테이션이 붙은 메서드가 어떻게 비동기로 처리되는지와 더불어 @EnableAsync 가 어떻게 동작하는지를 다뤄보겠다.

 

 

@EnableAsync 동작원리

@EnableAsync 

main() 메서드가 있는 클래스에 @EnableAsync 를 붙인 후 프로젝트를 실행했다.

디버거를 찍으면서 어떤 원리로 @Async 가 등록되는지 확인해보자. 

 

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(AsyncConfigurationSelector.class)
public @interface EnableAsync {
    ...
	AdviceMode mode() default AdviceMode.PROXY;
}

 

@EnableAsync 내부에서 AsyncConfigurationSelector 클래스를 임포트 하는 것을 확인할 수 있다.

AdviceMode는 PROXY 와 ASPECTJ 2가지 타입이 존재하는데 여기선 PROXY로 디폴트 설정된다.

PROXY 타입은 JDK proxy-based 로 인터페이스를 구현한 클래스에만 적용 가능하다.

 

 

 

AsyncConfigurationSelector

AsyncConfigurationSelector에서는 AdviceMode에 따라 ProxyAsyncConfiguration이나 AspectJAsyncConfiguration을 배열에 담아 리턴한다. 여기선 PROXY 모드를 사용하기 때문에 ProxyAsyncConfiguration 가 리턴된다. ProxyAsyncConfiguration 클래스로 이동해보자.

 

 

 

ProxyAsyncConfiguration

이곳에서 AsyncAnnotationBeanPostProcessor을 Bean으로 생성한다.

 

 

 

 

AsyncAnnotationBeanPostProcessor

해당 빈후처리기에선 AsyncAnnotationAdvisor를 어드바이저로 할당한다.

(AsyncAnnotationAdvisor는 BeanFactoryAware의 구현체로 setBeanFactory()를 오버라이드)

AsyncAnnotationAdvisor로 이동해 보자.

 

 

 

 

AsyncAnnotationAdvisor

AsyncAnnotationAdvisor의 생성자 부분이다.

복잡해 보이지만 결국 Advisor에선  advice와 pointcut을 할당하는 부분이 핵심이다.

마지막 두 라인에서 각각 buildAdvice()와 buildPointcut() 메서드로 값을 할당하고 있다.

 

 

중간 정리를 하자면 우리는 @EnableAsync의 동작과정을 파악하는 중이며 @EnableAsync는 @Async 가 동작하기 위한 사전 설정과정으로 알고 있다. 즉 @Async 가 붙은 메서드를 비동기로 처리하기 위한 스프링의 사전 설정과정이다. 지금까지의 과정을 살펴보면 @Async 가 동작하기 위해선 Proxy 설정과 AsyncAnnotationAdvisor 이 필요한 걸 알게 됐다.

 

다시 AsyncAnnotationAdvisor로 돌아와 해당 어드바이저엔 어떤 포인트컷과 어드바이스가 할당되는지 코드로 확인해 보자.

 

 

 

AsyncAnnotationAdvisor.buildAdvice()

advice는AnnotationAsyncExecutionInterceptor 가 할당된다.

 

 

 

 

AsyncAnnotationAdvisor.pointcut()

pointcut 에는 [..., interface org.springframework.scheduling.annotation.Async, ...] 이 할당되는 것을 확인할 수 있다. 즉 AsyncAnnotationBeanPostProcessor라는 빈 후처리기에 의해 @Async는 AsyncAnnotationAdvisor 가 동작할 수 있는 포인트컷이 된다.

 

 

다이어그램으로 확인하면 아래와 같다.

 

 

 

 

@Async 동작 과정

EnableAsync 가 어떤 식으로 동작하는지 파악했으니 실제로 @Async를 사용해 보자. 우선 애플리케이션 클래스에 @EnableAsync를 설정했다. 이로써 스프링부트가 실행될 때AsyncAnnotationAdvisor 가 등록되는 것을 위 과정을 통해 확인했다.

 

 

 

AsyncExecutionInterceptor

@Async 어노테이션이 붙은 메서드가 호출되면 AsyncExecutionInterceptor.invoke()에서 요청을 가로챈다.

위 다이어그램에서 AsyncAnnotationAdvice에 의해 AnnotationAsyncExecutionInterceptor 가 생성되는 것과 AsyncExecutionInterceptor 은 AnnotationAsyncExecutionInterceptor의 부모클래스란 걸 확인할 수 있다.

 

 

마지막 라인에서 doSubmit()가 호출되며, 해당 메서드는 AsyncExecutionAspectSupport 추상 클래스에 정의돼 있다.

이때 인자로 task 람다식과 executor를 넘겨 호출한다.

 

 

 

 

doSubmit

결국 @Async 어노테이션으로 선언된 메서드는 최종적으로 doSubmit() 로직에 따라 비동기로 동작한다. 이때 @Async 메서드의 리턴 타입에 따라 결과가 상이하게 구현된다.

이 리턴 타입은 doSubmit()의 세 번째 인자로 invoke() 메서드에서 invocation.getMethod().getReturnType()에 해당된다.

 

 

각각의 케이스는 4가지로 정리된다.

1. CompletableFuture

2. ListenableFuture

3. Future

4. void

 

CompletableFuture와 ListenableFuture는 모두 Future 인터페이스를 구현한다.

 

 

 

실습 코드를 통해 @Async 어노테이션이 선언된 메서드는 어떤 식으로 doSubmit() 내부에서 처리되는지 확인해 보자.

@RestController
@RequiredArgsConstructor
public class SampleController {

    private final AsyncService asyncService;

    @GetMapping("return-async-future")
    public void returnFuture() throws InterruptedException, ExecutionException {
        log.info("before Async");
        asyncService.completableFutureAsync()
            .thenAccept(result -> log.info("Return of Async | {}", result));
        log.info("after Async");
        return;
    }

}



@Service
public class AsyncService {

    @Async
    public CompletableFuture<Integer> completableFutureAsync() throws InterruptedException {
        log.info("middle of completableFutureAsync()");
        return new AsyncResult<>(1).completable();
    }
}

 

 

예시 코드의 출력 결과는 아래와 같다. 

@Async 처리된 completableFutureAsync() 내부의 로그가 'after Async' 보다 늦게 출력되는데, 이는 해당 메서드가 논블로킹 비동기식으로 처리됐음을 알 수 있다. 메서드의 결과는 callback 형식으로 thenAccept 내부에서 처리된다. 비동기 메서드의 결과를 리턴 받아 처리해야 한다면 thenAccep(), thenApply() 등의 메서드를 활용할 수 있다.

 

 

 

현재 케이스에서 @Async 달린 메서드의 리턴타입은 CompletableFuture로 첫 번째 분기문에 걸려 리턴된다.

해당 분기문에서 task를  submitCompletable() 메서드의 인자로 넘기고 최종적으로 CompletableFuture 클래스가 해당 task를 처리한다.

 

 

AsyncTaskExecutor.submitCompletable() -> FutureUtils.callAsync() -> CompletableFuture.completableAsync()

 

이때 우리는 별도의 executor를 지정하지 않았기 때문에 ThreadPoolTaskExecutor에서 해당 작업을 처리한다. 다만 이처럼 별도의 executor를 지정하지 않으면 ForkJoinPool의 CommonPool을 사용하게 되는데, 이는 애플리케이션 운영 시 예상치 못한 장애가 발생할 수 있으니 사용에 주의할 필요가 있다고 한다. (출처 : https://brunch.co.kr/@springboot/401 )

 

스프링부트 3.0 이전에는..

아래 코드는 스프링부트 2.7.8 버전의 doSubmit() 구현 로직으로 returnType 이 CompletableFuture 일 경우,

명시적으로 CompletableFuture.supplyAsync() 메서드를 호출하는 것을 볼 수 있다.

즉 @Async 어노테이션 선언된 메서드는 결국 CompletableFuture 클래스를 통해 비동기 로직이 처리되는 걸 확인할 수 있다.

 

---

정리

스프링부트에서 간단하게 비동기 호출을 적용할 수 있는 @Async의 동작원리를 살펴봤다.

정리하자면

- @Async는 @EnableAsync 를 필요로 하며 이는 Proxy 모드로 설정되어 있다.

- 즉 @Async 는 기본적으로 Spring AOP 제약사항을 따른다. 이때 pointcut 은 @Async, advice는 AnnotationAsyncExecutionInterceptor가 된다.

- @Async 메서드는 AsyncExecutionInterceptor에  동작이 인터셉트되고 리턴 타입에 따라 비동기 결과를 리턴한다.

- 결과적으로 @Async 어노테이션이 선언된 메서드는 내부에서 CompletableFuture 클래스에 의해 비동기로 동작한다.

 

결국 스프링에서 @Async를 통한 비동기로직의 핵심은 CompletableFuture라는 결론을 남기게 됐다. 다음 포스팅에선 이 CompletableFuture의 정체(?)와 원리에 대해 더 깊이 다뤄 볼 예정이다.

 

 

 

 

ref

https://brunch.co.kr/@springboot/401

https://blog.naver.com/gngh0101/222073112894