728x90

Virtual Thread란…?

JDK 21에 새롭게 들어온 개념 (2023.09.19 에 LTS 출시)
- gradle 8.4v 부터 지원
- kotlin v1.9.20 부터 21 바이트 코드 지원
- Spring 6.1, Spring boot 3.2 부터 지원
- Jetbrain Intellij 2023.3

JDK 21(LTS)에 추가된 경량 스레드, OS 스레드를 그대로 사용하지 않고 JVM 내부 스케줄링을 통해서 수십만 ~ 수백만개의 스레드를 동시에 사용할 수 있게한다.

전통적인 Java의 Thread

Java의 Thread는 OS Thread를 랩핑한 것 (Platform Thread)
Java 애플리케이션에서 Thread를 사용하면 실제로 OS Thread를 사용한 것
OS Thread는 생성 갯수가 제한적이고 생성, 유지하는 비용이 비쌈
이 때문에 애플리케이션에서는 플랫폼 스레드를 효율적으로 사용하기 위해 Thread Pool을 사용함

위와 같은 동작 매커니즘에의한 Throughput(처리량) 의 한계

기본적인 Web Request 처리 방식은 Thread Per Request(하나의 요청/하나의 스레드)
처리량을 높이려면 스레드 증가 필요, But 스레드는 한정적이다. (OS 스레드 제약)

특히나 Blocking I/O 쪽에서 많은 문제가 발생함.

Thread 에서 I/O 작업을 처리할 때, Blocking이 일어난다.
작업을 처리하는 시간보다 대기하는 시간이 길다.

그래서 우리는 Reactive Programming을 사용했었음.

Webflux 스레드를 대기하지 않고 다른 작업 처리 가능 (장점)
코드를 작성하고 이해하는 비용이 높다 (단점)
Reactive하게 동작하는 라이브러리 지원을 필요로 한다 (단점)
JPA를 사용할 수 없고 R2DBC라는 래퍼런스가 상대적으로 적은 라이브러리를 사용해야 함 (단점)

그렇다면 왜 이렇게 구성이 되어있을까…?

Java Design

자바의 디자인은 ‘스레드 중심’으로 구성되어있다.
Exception Stack trace, Debugger, Profiling 모두 스레드 기반
Reactive할 때, 작업이 여러 스레드를 거쳐 처리되는데, 컨택스트 확인이 어려워 디버깅이 어려움.

Virtual Thread가 해결하고자하는 문제

애플리케이션의 높은 처리량 확보
- Blocking 발생시 내부 스케줄링을 통해 다른 작업을 처리 (= 기존 자바의 한계)
자바 플랫폼의 디자인과 조화를 이루는 코드 생성
- 기존 스레드 구조 그대로 사용(= Webflux가 못한부분)

결론은 Virtual Thread는 Reacitve와 MVC의 장점만 차용한 케이스!

Virtual Thread가 앞에 따로 존재함.
뒤에 Fork/Join Pool이 Carrier Thread(Platform Thread와 거의 동일한 형태)
Carrier Thread는 OS Thread와 1:1 매핑되는 구조이긴 하지만 실제 Application에서는 Platform Thread가 아니라 Virtual Thread만 사용하게된다.

Virtual Thread가 Blocking되면 Virtual Thread와 Carrier Thread에서 Unmount 된다.
그리고 다른 Virtual Thread가 해당 Carrier Thread와 Mount 된다.
OS Thread가 갯수에 제한이 있는 것에 비해서 Virtual Thread는 엄청난게 많이 생성할 수 있다.

사용법 예시

// Virtual Thread 방법 1
Thread.startVirtualThread(() -> {
    System.out.println("Hello Virtual Thread");
});

// Virtual Thread 방법 2
Runnable runnable = () -> System.out.println("Hi Virtual Thread");
Thread virtualThread1 = Thread.ofVirutal().start(runnable);

// Virtual Thread 이름 지정 
Thread.Builder builder = Thread.ofVirtual().name("JVM-Thread");
Thread virtualThread2 = builder.start(runnable);

// 스레드가 Virtual Thread인지 확인하여 출력
System.out.println("Thread is Virtual? " + virtualThread2.isVirtual());

// ExecutorService 사용 
try(final ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 3; i++) {
        executorService.submit(runnable);
    }
}

Spring Boot(MVC) 적용법 (3.2 이상)

# application.yaml

spring:
  threads:
    virtual:
      enabled: true

Spring Boot(MVC) 적용법 (3.x)

// Web Request를 처리하는 Tomcat이 Virtual Thread를 사용하여 유입된 요청을 처리하도록 한다. 
@Bean
public TomcatProtocolHandlerCustomizer<?> protocolHandlerVirtualThreadExecutorCustomizer() {
    return protocolHandler -> {
        protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
    }
}

// Async Task에 Virtual Thread 사용
@Bean(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME)
public AsyncTaskExecutor asyncTaskExecutor() {
    return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor());
}

유의사항

유의사항 1

Platform Thread => Virtual Thread (X)
- 전통적으로 사용하던 이 개념으로 Virtual Thread를 쓰게되면 성능 향상을 체감할 수 없을 것이다.
Task => Virtual Thread (O)

리소스라고 생각하기보다는 Task별로 Virtual Thread 할당

유의사항 2

Thread Local 사용시 주의

Platform Thread Pool을 사용할 때, 공유를 위해 ThreadLocal을 사용하던 관습
Virtual Thread는 Heap을 사용하기 때문에 이를 남발하면 메모리 사용이 늘어남.
- Platform Thread와는 달리 Virtual Thread는 수십 수백만개까지 생성될 수 있기 떄문에 메모리 점유량이 확 늘어날 수 있어 메모리 이슈 발생 가능성이 있음.

유의사항 3

synchronized 사용시 주의

synchronized 사용시 Virtual Thread에 연결된 Carrier Thread가 Blocking 될 수 있으니 주의
(이런 경우를 pinning 이라고 함)

// synchronized 사용 (pinning 발생)
// 순차적 접근을 보장한다. 
public synchronized String accessResource() {
    return access();
}

// ReentrantLock 사용 (pinning 발생하지 않음)
private static final ReentrantLock LOCK = new ReentrantLock();

public String accessResource() {
    // 순차적 접근을 보장한다.
    LOCK.lock();
    try {
        return access();
    } finally {
        LOCK.unlock();
    }
}

I/O와 관련된 부분에 있어서는 Virtual Thread를 적용했을 때, 상당히 큰 효과를 누릴 수 있다.

적합한 사용처

I/O Blocking이 발생하는 경우 Virtual Thread가 적합
CPU Intensive 작업에는 적합하지 않음
- ex) 이미지 프로세싱을해서 썸네일을 만든다. 동영상 인코딩을 한다거나. (I/O Intensive 작업이 아니라 CPU Intensive 작업이기 때문에 Virutal Thread를 도입한다고해서 크게 달라질게 없다)
Spring MVC 기반 Web API 제공시 편리하게 사용할 수 있다.
- 높은 Throughput을 위해서 Webflux를 고려중이라면 대안이 될 수 있다.
- Webflux 도입에도 (1)Stream 형태의 서비스를 제공해야하는 경우 vs (2)단순히 많은 처리를 하고 싶어서 가 있을 수 있는데, 이 중 (2)의 케이스는 Virtual Thread라는 새로운 대안으로 고민해볼 수 있다.

Virtual Thread에 대한 오해

Virtual Thread는 기존(Platform) Thread를 대체하는 것이 목적이 아니다.
Virtual Thread는 기다림에 대한 개선, 그리고 플랫폼 디자인과의 조화
도입한다고 무조건 처리량이 높아지지 않는다.
Virtual Thread는 그 자체로 Java의 동시성을 완전히 개선했다고 보기는 어렵다.

Virtual Thread의 제약

Thread Pool에 적합하지 않다. Task 별로 Virtual Thread를 할당해야 함
Thread Local 사용시 메모리 사용이 늘어날 수 있음
synchronized 사용시 주의가 필요함. (carrier thread가 blocking 될 수 있음)
- ReentrantLock을 사용
제한된 리소스의 경우 semaphore를 사용

참고 자료

https://www.youtube.com/watch?v=vQP6Rs-ywlQ
https://techblog.woowahan.com/15398/