Spring Boot 3.x에서 Virtual Threads 활용하기

개요

Java 21에서 정식 출시된 Virtual Threads는, OS가 직접 스케줄링하는 플랫폼 스레드와 달리 JVM이 소수의 캐리어(플랫폼) 스레드 위에 다중화해 스케줄링하는 경량 스레드입니다. 블로킹이 발생하면 가상 스레드는 캐리어에서 내려오고(unmount), 캐리어는 다른 가상 스레드를 실행합니다. Spring Boot 3.2부터 공식 지원이 추가됐습니다.

기존 방식의 한계

Spring MVC의 기본 스레드 모델은 요청당 하나의 OS 스레드를 사용합니다.

@RestController
public class UserController {

    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        // I/O 블로킹 — 이 스레드는 응답까지 점유됨
        return userService.findById(id);
    }
}

I/O가 많은 워크로드에서는 스레드가 블로킹 상태로 대기하며 리소스를 낭비합니다.

Virtual Threads 활성화

Spring Boot 3.2+ 환경에서는 설정 한 줄로 활성화할 수 있습니다.

spring:
  threads:
    virtual:
      enabled: true

또는 Java Config로:

@Configuration
public class VirtualThreadConfig {

    @Bean
    public TomcatProtocolHandlerCustomizer<?> virtualThreadCustomizer() {
        return handler ->
            handler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
    }
}

성능 비교

위 수치는 I/O 블로킹이 많은 워크로드를 가정한 예시이며, 실제 값은 워크로드·하드웨어·다운스트림 자원에 따라 달라집니다.

주의사항

Virtual Threads는 CPU-bound 작업이 아닌 I/O-bound 작업에 효과적입니다. synchronized 블록 안에서 블로킹하거나 네이티브 메서드(JNI/FFI)를 호출하면 캐리어 스레드를 핀닝(pinning)해 오히려 성능이 저하될 수 있습니다. 다만 JDK 24(JEP 491)부터 synchronized 블로킹으로 인한 핀닝은 해소됐습니다 — JDK 21~23에서는 ReentrantLock 사용을 권장합니다. 또한 다운스트림 자원(예: DB 커넥션 풀)이 병목이면 가상 스레드를 아무리 늘려도 처리량은 그 한계에 묶입니다.

마무리

기존 Spring MVC 코드를 변경하지 않고 설정만으로 처리량을 크게 개선할 수 있는 것이 Virtual Threads의 강점입니다. Spring Boot 3.2+ 프로젝트에서 I/O 집약적인 서비스라면 적극 도입을 권장합니다.