동기, 비동기 / 블로킹, 논블로킹 (@Async)

 

매일메일 백엔드 질문을 참고해 개인적으로 학습한 내용을 정리하였습니다.
오류가 있다면 언제든 피드백 주시면 바로 반영하겠습니다..!

 

 

 

동기(Synchronous) vs 비동기(Asynchronous)

 

동기(Synchronous): 함수 A가 함수 B를 호출하면, A는 B의 작업이 끝날 때까지 기다리는 것임 

 

=> B의 작업이 완료되고 결과값이 반환된 후에야 A는 다음 작업을 이어서 수행할 수 있음

(모든 작업이 순차적으로 진행)

 

 

비동기(Asynchronous): 함수 A가 함수 B를 호출할 때, A는 B의 작업 완료 여부를 신경 쓰지 않고 즉시 다음 코드를 실행하는 것임 

 

=> B는 별도의 흐름에서 작업을 수행하며, 작업이 완료되면 콜백(Callback), 이벤트(Event), 또는 다른 메커니즘을 통해 A에게 결과를 알림
(작업이 순차적으로 진행되지 X)

 

이 둘의 차이는 호출하는 함수(Caller)가 호출받는 함수(Callee)의 작업 완료를 기다리는지 여부임

=> 즉, 결과를 돌려받는 시점과 작업 흐름의 순서에 대한 관점으로 볼 수 있음

 

블로킹(Blocking) vs 논블로킹(Non-Blocking)

 

블로킹(Blocking): 함수 A가 함수 B를 호출하면, 제어권이 B로 넘어가는 것임 

 

=> B가 작업을 모두 마치고 제어권을 반환할 때까지 A는 실행을 멈추고 대기 상태(Blocked)에 빠짐

 

 

논블로킹(Non-Blocking): 함수 A가 함수 B를 호출하면, B는 작업을 시작하고 즉시 제어권을 A에게 반환하는 것임

 

=> A는 B의 작업 완료 여부와 상관없이 자신의 코드를 계속해서 실행할 수 있음

 

이 둘의 차이는 호출하는 함수가 호출받는 함수를 부른 직후 제어권을 돌려받을 수 있는지 여부임

=> 즉, 제어권의 소유에 대한 관점으로 볼 수 있음

 

예시로 살펴보기

 

카페에서 커피를 주문하는 상황으로 위 조합들을 살펴보면

 

1. 동기-블로킹 (Sync-Blocking)

 

커피를 주문하고, 커피가 나올 때까지 카운터 앞에서 아무것도 못 하고 계속 기다림

 

=> 작업 완료를 기다리며(동기), 제어권도 넘어가서 멈춰있음(블로킹)

 

2. 동기-논블로킹 (Sync-Non-Blocking)

커피를 주문하고 제어권은 바로 돌려받았지만(논블로킹), 커피가 언제 나오는지 궁금해서 1초마다 "제 커피 나왔나요?"라고 계속 물어봄

 

=> 작업 완료를 직접 계속 확인해야 하므로(동기), 다른 중요한 일을 하지는 못함
(제어권은 바로 받지만, 동기이기 때문에 내가 직접 완료 여부를 체크해야 함)

 

3. 비동기-블로킹 (Async-Blocking)

커피 주문을 매니저에게 위임(비동기 호출)하고 다른 일을 보려 했지만, 그 매니저가 커피가 나올 때까지 카운터 앞에서 하염없이 기다림(블로킹)

 

=> 호출 자체는 비동기적이었으나, 결과를 받아야 하는 다른 주체가 블로킹되는 특이한 경우임

 

Java의 Future.get()

 

Java에서 Future.get()이 대표적인 예시인데 Future.get()은 비동기로 실행한 작업의 결과를 가져오는 메서드임

=> 결과가 아직 안 나왔으면 그 자리에서 기다리는(블로킹) 특징이 있음

간단하게 흐름을 살펴보면

 

Future 객체는 ExecutorService.submit() 같은 비동기 작업 제출 결과로 반환됨

 

ExecutorService.submit()을 호출하면 작업을 백그라운드 스레드(스레드 풀 내부 스레드)에서 실행하도록 예약하는데 이때 반환되는 게 Future 객체임

=> 이 Future는 "아직 결과가 안 나왔지만, 나중에 이걸 통해 결과를 꺼낼 수 있다"는 Promise 같은 역할을 함

 

ExecutorService executor = Executors.newSingleThreadExecutor();

Future<String> future = executor.submit(() -> {
    Thread.sleep(2000); // 2초 걸리는 작업
    return "커피 완성!";
});

System.out.println("다른 일 하는 중...");
String result = future.get(); // 결과 나올 때까지 블로킹
System.out.println(result);

executor.shutdown();

 

 

 

호출 자체는 비동기(작업은 별도 스레드에서 실행)지만 get()은 결과 받을 때까지 현재 스레드(호출한 스레드)를 블로킹하기에  비동기 + 블로킹이라는 특이한 조합이 됨

 

(작업 실행 스레드는 계속 일하고있고 호출한 쪽 스레드는 get()에서 멈춰서 기다림)

 

 

4. 비동기-논블로킹 (Async-Non-Blocking)

 

커피를 주문하고 진동벨을 받아서 자리에서 자유롭게 할걸 함(논블로킹) 그러다 나중에 진동벨이 울리면(Callback), 그때 커피를 찾으러 감

 

=> 작업 완료를 기다리지 않고(비동기), 제어권도 바로 돌려받음

 

Spring에서 비동기 처리 (@Async)

 

Spring에서는 @Async 어노테이션을 통해 비동기-논블로킹 패턴을 매우 간단하게 구현할 수 있음

 

=> 회원가입 후 이메일 발송, 푸시 알림, 대용량 파일 처리 등 즉각적인 응답이 필요 없는 작업을 비동기로 전환하여 사용자 경험을 크게 향상시킬 수 있음

 

사용법

 

1. 비동기 기능 활성화: @Configuration 클래스에 @EnableAsync를 추가합니다.
    

   import org.springframework.context.annotation.Configuration;
   import org.springframework.scheduling.annotation.EnableAsync;
   
   @Configuration
   @EnableAsync
   public class AsyncConfig {
       // (필요 시 스레드 풀 커스터마이징)
   }
   

    

2. @Async 적용: 비동기로 실행할 public 메서드에 @Async를 붙여줍니다.
    

   import org.springframework.scheduling.annotation.Async;
   import org.springframework.stereotype.Service;
   
   @Service
   public class NotificationService {
   
       @Async
       public void sendWelcomeEmail(String email) {
           System.out.println(Thread.currentThread().getName() + "에서 환영 이메일 발송 시작...");
           try {
               Thread.sleep(3000); // 3초가 걸리는 작업이라 가정
           } catch (InterruptedException e) {
               Thread.currentThread().interrupt();
           }
           System.out.println(email + "님에게 환영 이메일 발송 완료!");
       }
   }
   

    

이제 다른 곳에서 sendWelcomeEmail 메서드를 호출하면, Spring은 이 메서드를 별도의 스레드에서 실행하고 즉시 다음 코드로 넘어감

 

@Async 사용 시 반드시 알아야 할 주의사항 

 

1. 예외(Exception)는 호출자에게 전파되지 않는다

 

@Async
public void asyncJob() {
    throw new RuntimeException("문제 발생!");
}

public void caller() {
    try {
        asyncJob();
    } catch(Exception e) {
        System.out.println("잡혔나?"); // X, 잡히지 않음
    }
}

 

@Async가 적용된 메서드는 별도의 스레드에서 동작하기 때문에, 내부에서 발생한 예외는 호출자(Caller)의 try-catch 블록에 잡히지 않음

 

해결책

 

@Async
public Future<String> asyncJob() {
    if(true) throw new RuntimeException("문제 발생");
    return new AsyncResult<>("OK");
}

Future<String> future = asyncJob();
try {
    future.get(); // 이 시점에서 예외를 받을 수 있음
} catch(Exception e) { ... }

 

• Future 또는 CompletableFuture 사용: 반환 타입을 Future<T>나 CompletableFuture<T>로 설정하면 비동기 작업의 결과를 추적하고 .get() 메서드를 호출하는 시점에 예외를 받을 수 있음
• AsyncUncaughtExceptionHandler 구현: void를 반환하는 비동기 메서드의 예외를 전역적으로 처리하기 위한 핸들러를 직접 구현할 수 있음

 

2. 프록시(Proxy) 기반으로 동작한다

 

@Async는 Spring AOP(Aspect-Oriented Programming) 프록시를 통해 동작함

 

스프링이 @Async가 붙은 빈을 만들 때, 실제 객체 대신 프록시 객체를 스프링 컨테이너에 등록하고 다른 코드에서 프록시를 호출하면 프록시가 호출을 가로챔
(어플리케이션 코드에서 @Autowired와 같이 의존성을 주입받아 메서드를 호출할 때 Spring은 실체 객체가 아닌 프록시 객체를 주입해줌)

=> @Async를 확인하고 별도 스레드에서 실행 후 원래 메서드로 전달

(즉, @Async는 실제 메서드가 아니라 프록시가 대신 실행하는 구조임)

 

이와 같이 AOP 프록시를 통해 동작하기 때문에 같은 클래스 내부에서 @Async 메서드를 직접 호출(this.method())하면 비동기로 동작하지 않음 

 

=> 프록시를 거치지 않고 실제 객체의 메서드를 호출하기 때문

 

일반적으로 객체 호출을 대신 처리만 하는 프록시와 다르게 AOP 프록시는 객체 호출 전후로 공통 기능을 적용할 수 있음

=> @Async가 동작하려면 스레드 풀에서 실행하라는 Advice를 넣을 수 있게 AOP 프록시를 거쳐야함

 

해결책

 

• 클래스 분리: @Async 메서드를 별도의 클래스로 분리하고, 해당 클래스를 주입(DI)받아 호출하는 것이 가장 명확하고 좋은 방법임
  
  
• 자기 자신 주입: 자기 자신 타입의 객체를 주입받아 프록시를 통해 호출하는 방법도 가능

 

3. 트랜잭션의 생명주기는 분리된다

 

@Async 메서드는 새로운 스레드에서 동작하기 때문에 호출자 스레드의 트랜잭션 컨텍스트를 이어받지 않음

 

트래잭션 컨텍스트는 트랜잭션 정보를 담은 스레드 단위 상태로 Spring에서 트랜잭션은 스레드-로컬(ThreadLocal)로 관리됨

=> 즉, 비동기 메서드 내에서 생성한 트랜잭션은 상위 트랜잭션과 무관한 생명주기를 가짐
(호출자의 트랜잭션이 롤백되어도 비동기 메서드의 트랜잭션은 커밋될 수 있음)

 

비동기 작업이 반드시 트랜잭션을 필요로 한다면, @Async 메서드에 직접 @Transactional 어노테이션을 붙여 새로운 트랜잭션을 시작해야함