Virtual Thread 은 무엇일까?

1. Java Virtual Thread?

 Java Virtual Thead 는 LTS 인 Java21 부터 정식 도입된 경량성 스레드이다.

 

기존 자바 스레드 모델은 OS scheduler 를 통해 스케줄링하는 스레드 모델인 반면,

가상 스레드는 JVM 에서 스케줄링하는 경량성 스레드 모델이다.

 

JVM 자체적인 내부 스케줄링을 통해 기존 스레드에 비해 최대 가용 스레드 수를 증가시켜

높은 처리량을 달성하기 위한 목적으로 도입된 개념이다.
 

2. Java Thread 은 JNI 기반으로 스레드를 생성한다.

 기존 스레드는 OS Thread 를 래핑한 형태로 OS 스레드와 유저 스레드를 1:1 매핑하는 형태이다.

 

기존 스레드의 실행과 생성은 JNI(Java Native Interface) 가 담당했다. JNI 는 다른 프로그래밍 언어(주로 C, C++) 로 작성된 네이티브 코드 간의 상호 운용을 가능하게 하는 프레임워크이다. 즉, JVM 에서 다른 프로그래밍 언어를 사용할 수 있도록 지원함을 의미한다.

 

Thread 클래스의 내부 코드를 확인하면 native 키워드를 확인할 수 있다. JNI 가 해당 부분을 담당하여 JVM 내에 스택과 분리되어 있는 네이티브 메서드 스택(Native Method Stack) 을 사용해 C 언어를 실행시킨다.

public class Thread implements Runnable {

    private native void start0();

    public synchronized void start() {
        // ...
        try {
            start0();
            started = true;
        } finally {
            //...
        }
    }
}

ref : https://github.com/openjdk/jdk21/blob/master/src/java.base/share/native/libjava/Thread.c#L39

 

[스레드 start() 메서드 호출 정리]

 
 

3. 기존 스레드의 문제점 : Blocking 으로 인한 리소스 낭비 및 처리량 한계

 기존 스레드는 OS level thread 를 생성해 래핑한 형태이다. 이를 플랫폼 스레드(platform thread) 로 정의한다.

결국 실제 스레드를 사용하는 코드는 OS level thread 를 이용한다. 하지만 OS kernel 에서 사용할 수 있는 스레드 갯수는 제한적이므로 스레드를 무한정으로 늘릴 수 없는 단점이 있다.

  Spring Web 과 같이 Thread per Request 모델에서 I/O 작업을 처리하면 해당 요청이 완료될 때까지 해당 스레드는 Blocking 된다. 이로 인해 해당 스레드는 I/O 작업이 완료될 때까지 대기해야 하므로 리소스 낭비가 발생할 수 있다. 이를 개선하기 위해서 Blocking 방식으로 인해 대기하는 리소스 낭비를 최소화에 관한 고민이 필요했다.

 
 또한 이와 같은 구조는 높은 처리량에 있어 한계가 있다. 스케일 아웃(scale-out) 을 통해 전체 처리량을 늘릴 수 있지만, 단일 애플리케이션 서버의 처리량을 개선하기 위해서는 앞서 이야기한 Blocking 방식으로 인한 시간을 최소화하는 방법에 관한 고민이 필요하다.

 

이와 같은 고민을 해결하기 위해 Non-blocking 기반의 Reactive Programming 도입을 검토가 필요하다. 하지만 reactive programming 적용을 위한 러닝 커브가 존재하고, 자바는 스레드 기반으로 설계되어 컨텍스트 확인에 어려움이 존재했다. (e.g. Exception)

가상 스레드 도입 이전 스레드 구조

 
 

4. 해결하고자 하는 문제 : Virtual Thread 를 통한 Blocking 방식의 리소스 낭비 개선

위와 같은 문제를 해결하기 위해 자바 진영에서는 2018년 Project Loom 프로젝트를 출범했다. Project Loom 은 자바 동시성 모델을 획기적으로 개선하기 위한 프로젝트이다. 가상 스레드를 도입해 기존의 무거운 OS thread 기반의 구조를 개선하고자 하는 목적이다.

 

Project Loom 은 JVM 을 통한 스케줄링, KB 단위 스택(기존 스레드 : MB 단위), 기존 코드 변경 최소화를 통해 기존의 Blocking 방식에 관한 문제를 해결할 수 있는 방법을 제시했다.
 
기존의 방식과의 가장 큰 차이점은 작업 스레드와 OS 스레드의 분리이다. 작업에 관한 역할은 가상 스레드에 위임하고, OS 스레드와 매핑하는 책임을 캐리어 스레드(carrier thread)에 위임했다.

 

이를 통해 누릴 수 있는 장점은 가상 스레드는 블로킹되지만, OS 스레드는 블로킹되지 않는다는 점이다. Non-blocking 과 같이 OS 스레드를 대기시키지 않아 스레드 자원을 절약하여 처리량 개선을 기대할 수 있게 되었다.
 
 

(1) Virtual Thead 의 동작 방식

 가상 스레드는 JVM 스케줄링을 통해 관리하는 유저 레벨 스레드이다. 가상 스레드는 필요할 때만 OS 스레드를 사용한다. 만약 I/O 작업으로 인해 작업이 블로킹되면 스택을 저장하고 실행 중인 OS 스레드를 반납한다.

 

JVM 은 가상 스레드와 OS 스레드를 연결하는 스케줄링을 담당하며, 이 작업을 mount/unmount 라 한다. (실제 내부 코드에서는 park/unpark 이름으로 사용한다.)

 가상 스레드는 캐리어 스레드와 연결을 통해 OS 스레드와 매핑한다. 만약 I/O 작업으로 인해  블로킹 되는 경우, JVM 스케줄링을 통해 캐리어 스레드와 연결을 해지하고(unmount), 다른 가상 스레드와 연결하여 해당 가상 스레드의 작업을 진행한다.(mount)

가상 스레드 도입 이후 스레드 구조

 
 

(2) Virtual Thread 의 장점

i. 컨텍스트 스위칭 비용 절감

 가상 스레드는 컨텍스트 스위칭(context switching) 비용을 절감할 수 있다.

 

기존 플랫폼 스레드는 OS 레벨의 컨텍스트 스위칭이 발생한다. OS 레벨의 컨텍스트 스위칭은 커널의 관여로 인해 시스템 콜, CPU 레지스터 상태 저장, 스택 포인터 이동과 같은 작업으로 비용이 크다.

 

반면, 가상 스레드은 유저 레벨인 JVM 내부에서 처리한다. 즉, 컨텍스트 스위칭에 커널이 개입이 상대적으로 적다.

 

만약 스레드가 블로킹 호출에 진입하면 현재 스택 프레임을 heap에서 관리하고, 캐리어 스레드는 즉시 다른 가상 스레드로 전환되어 비용이 낮다. 이로 인해 기존 플랫폼 스레드에 비해 빠른 컨텍스트 스위칭으로 인해 스레드 관리에 관한 부담이 적다.

기존 자바 컨텍스트 스위칭

가상 스레드 컨텍스트 스위칭

 

ii. 스레드 생성 비용 감소

 기존 플랫폼 스레드는 JVM 메모리 영역 내에서 각 스레드별로 필요한 메모리 공간을 새로 할당한다. (예. 프로그램 카운터, 스택, 네이티브 메서드 스택 등)

 

반면, 가상 스레드는 이와는 다른 방식으로 동작한다. 가상 스레드는 실행 중인 가상 스레드 정보는 캐리어 스레드의 메모리 영역을 공유하고, 블로킹된 상태에서는 스레드 상태 정보가 힙 영역에 저장된다.

 

즉, 플랫폼 스레드는 스레드마다 고유한 메모리 공간을 요구하는 반면, 가상 스레드는 소수의 캐리어 스레드 메모리와 힙을 활용함으로써 메모리 사용량을 줄이고, 스레드 생성에 필요한 자원 소모를 최소화할 수 있다.

메모리 구조 차이

 

5. 가상 스레드 사용 시 유의사항 : pinning

가상 스레드는 자바 런타임이 스케줄링한다.

자바 런타임은 가상 스레드를 실행할 때, 이를 캐리어 스레드에 마운트 시키고, 이 캐리어 스레드는 운영 체제에 의해 일반 스레드처럼 실행된다. 가상 스레드는 코드 실행 도중 I/O와 같은 블로킹 작업을 만나면 캐리어 스레드에서 언마운트되어 다른 가상 스레드가 해당 캐리어 스레드를 사용할 수 있게 된다.

 

하지만 다음과 같은 경우에는 가상 스레드가 캐리어 스레드에 고정(pinned)되어 언마운트되지 못한다.

• synchronized 블록이나 메서드 안에서 실행 중일 때
• 네이티브 메서드나 외부 함수(예: Foreign Function and Memory API)를 실행할 때

 

 이와 같은 현상이 발생하면 캐리어 스레드는 작업을 진행하지 않고 해당 CPU 는 격리된다. 이는 시스템 성능이 저하되거나 데드락과 같은 문제를 야기할 수 있기 때문에 가상 스레드를 사용하기 이전에 고정 이슈 발생 가능 지점을 미리 확인해야 한다.
 
가상 스레드를 검토하고 있다면 가장 먼저 검토해보야할 요소가 synchronized 이다.

synchronized 키워드를 사용한다면 가상 스레드를 언마운트하지 못해 pinned 상태가 된다. 그러므로 가상 스레드를 검토하고 있다면 synchronized 사용을 지양해야 한다.

 

만약 동시성 해결을 위해 synchronized 를 사용하고 있다면 ReentrantLock 으로 대체하는 방안을 검토해야 한다. 그리고 synchronized 사용 지점을 검토해야 한다면 애플리케이션 뿐만 아니라 사용 라이브러리까지 synchronized 사용 여부를 검토해야 고정 이슈 발생을 방지할 수 있다.

PINNING 으로 인한 CPU 격리 도식화

 

(1) Pinning 이슈를 개선한 Java24

[2025.04.15 update]
Java24 가 2025.03.18 에 도입된 개선안 중 JEP 491: Synchronize Virtual Threads without Pinning 을 살펴보면 기존의 Pinning 이슈가 개선 되었다.
 
기존 synchronized 메서드/블록 가상 스레드가 진입하면 JVM 이 해당 가상 스레드의 캐리어 스레드가 모니터를 가진 것으로 기록 되었다. 해당 이슈는 캐리어가 스레드가 다른 가상 스레드로 마운트 될 때, 기존 모니터를 가진 것으로 오인해 동기화 이슈가 발생할 수 있어 이를 방지하기 위해 JVM 은 synchronized 메서드/블록 내에 가상 스레드가 언마운트하는 것을 금지하고, 캐리어 스레드를 고정시켰다. 하지만 이 방식은 가상 스레드의 장점을 없애고, 오히려 설계 시 외부 라이브러리의 synchronzied 까지 고려해야 해서 설계적으로 고려해야 하는 사항이 많아지는 단점이 있었다.

Java24 이전 모니터락 구성

 
 
Java24 부터 synchronized 메서드/블록 내에서 블로킹되는 가상 스레드가 플랫폼 스레드를 해제할 수 있도록 JVM 을 개선했다. 이를 통해 가상 스레드가 캐리어 스레드에 고정(pinned) 되는 상황을 제거하고 동기화를 고려해야 하는 상황에서 가상 스레드의 동시 실행이 가능해 애플리케이션 확장성이 향상되었다. 또한, 기존 Java 라이브러리 수정 없이, 가상 스레드와 syncrhonized 의 호환성이 확보되어 기존에 외부 라이브러리에 관한 고민이 현저히 줄어들었다.

Java24 이후 모니터락 구성

 
하지만 실제 운영 환경에서 Java24 의 개선사항을 도입하는 것은 고민이 필요하다. 일반적으로 운영 안정성을 위해서 주로 LTS (Long Term Support) Version 을 사용한다. 아쉽게도 Java24 는 LTS 가 아니므로 해당 버전을 도입하는 것은 시기상조이다. oracle read map 을 확인해보면 2025.09 에 LTS 인 Java 25가 출시 예정이므로 해당 개선사항 적용을 위해서는 Java25 도입을 고민해보면 좋을 듯하다.

ref : https://www.oracle.com/kr/java/technologies/java-se-support-roadmap.html

 

6. 가상 스레드 사용 방법

(1) 자바에서 사용 방법 

 가상 스레드는 Java 21 부터 정식으로 릴리즈 되어 Java21 이후 버전부터 가상 스레드 사용이 가능하다.
스레드 생성 방법은 Thread 클래스의 빌더를 사용하거나 Exetutors 에서 제공하는 메서드를 사용할 수 있다.
 
Thread 클래스는 ofVirtual() 메서드를 통해 가상 스레드를 생성할 빌더 클래스를 선언할 수 있다. 해당 메서드 선언 이후 start() 메서드를 사용하면 가상 스레드를 생성하여 명령을 실행한다. 이와 반대로 플랫폼 스레드를 생성할 ofPlatform() 메서드 또한 제공하므로 참고하도록 하자.

/**
 * current thread name: cooper virtual thread
 * current thread is virtual: true
 * Hello virtual Thread 
 * 
 * current thread name: cooper platform thread
 * current thread is virtual: false
 * Hello platform Thread 
 */

public class Main {
	public static void main(String[] args) throws Exception {
		Runnable runnable = () -> {
			System.out.println("current thread name: " + Thread.currentThread().getName());
			System.out.println("current thread is virtual: " + Thread.currentThread().isVirtual());

			final String threadType = Thread.currentThread().isVirtual() ? "virtual" : "platform";
			System.out.printf("Hello %s Thread \n", threadType);
		};

		final Thread virtualThread = Thread.ofVirtual().name("cooper virtual thread").start(runnable);

		Thread.sleep(1000);

		final Thread platformThread = Thread.ofPlatform().name("cooper platform thread").start(runnable);

		virtualThread.join();
		platformThread.join();
	}
}

 
 
스레드 풀에 관한 팩토리/유틸리티 메서드를 제공하는 Executors 클래스 또한 가상 스레드를 생성하는 팩토리 메서드를 제공한다. 팩토리 메서드인 Executors.newVirtualThreadPerTaskExecutor() 은 submit(Runnable) 메서드를 호출할 때마다 새 가상 스레드를 생성해 작업을 실행한다. 
 
 아래 예제는 가상 스레드를 실행하고 5초간 블로킹을 했을 때 실행 시간을 확인하는 코드이다. 기존 플랫폼 스레드는 각 스레드가 블로킹으로 인해 OS 스레드까지 대기하기 때문에 실행 시간이 길지만, 가상 스레드는 해당 가상 스레드를 블로킹하지만 다른 가상 스레드는 캐리어 스레드에 의해 명령을 실행하여 약 5초에 가까운 소요 시간으로  실행이 완료되었다. 이를 통해 I/O bound 가 높은 연산의 서버에 높은 처리 성능을 기대할 수 있다.

/*
 * elapsed time = 5025ms
 */
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class Main {
	public static void main(String[] args) throws Exception {
		final long startTime = System.currentTimeMillis();

		try (final ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor()) {
			for (int i = 0; i < 1000; i++) {
				executorService.submit(() -> {
					try {
						Thread.sleep(5000);
					} catch (InterruptedException e) {
						throw new RuntimeException(e);
					}
				});
			}
		}

		final long endTime = System.currentTimeMillis();

		System.out.println("elapsed time = " + (endTime - startTime) + "ms");
	}
}

 

(2) 스프링에서 사용 방법 

참고로 2023.11.23 부터 Spring Boot 3.2 가 정식 릴리즈 되면서 Java21 을 지원한다.
(참고로 Gradle 버전은 8.4 버전 이상부터 Java21 을 지원한다.) 
 
Spring Boot 3.2 부터 Tomcat 의 사용자 요청을 virtual thread 기반으로 처리가 가능하다. 기존 플랫폼 스레드 기반으로 요청을 처리하던 방식을 가상 스레드를 생성해 사용자 요청을 처리하는 방식으로 변경할 수 있다. 스프링에서 제공하는 spring.threads.virtual.enabled 프로퍼티를 통해 간단한 설정이 가능하다. 옵션을 true 로 설정했을 경우, 가상 스레드를 기반으로 요청을 처리하는 방식으로 동작한다.  (defaut 는 false 이다.)

spring:
  threads:
    virtual:
      enabled: true

 
 
 하지만 해당 옵션을 true 로 설정에 관해서는 검토가 필요해 보인다. kakaopay 에서 진행한 요청 스레드를 가상 스레드로 전환을 위한 테스트 결과를 보면 Back Pressure 미수행, 잦은 GC로 인한 일시적 응답 지연, synchronized 로 인한 pinning 이슈로 인해 비동기 I/O bound 작업에 한해서 가상스레드를 적용을 결정했다.
(예 : VirtualThreadTaskExecutor)

import java.util.concurrent.Executor;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.task.VirtualThreadTaskExecutor;
import org.springframework.core.task.support.TaskExecutorAdapter;
import org.springframework.scheduling.annotation.EnableAsync;

@EnableAsync
@Configuration
public class AsyncConfig {

	private static final String ASYNC_THREAD_PREFIX = "virtual-thread-task-";

	@Bean
	public Executor someTaskExecutor() {
		return new TaskExecutorAdapter(new VirtualThreadTaskExecutor(ASYNC_THREAD_PREFIX));
	}
}

 

7. 회고

이번 글에서는 가상 스레드에 관해 살펴보았다.

기존 자바의 스레드 기반의 설계 방식을 유지하면서 성능 개선을 기대할 수 있는 방법으로 활용 가능한 개념이다.

 

우선 I/O bound 가 많은 API 서버에서 비동기로 처리했을 때의 효과가 가장 크고 현업에서도 많이 활용하고 있는 방식으로 파악된다. 참고로 CPU bound 작업에서는 가상 스레드의 효과가 크지 않기 때문에 I/O bound 작업에서 검토해볼만한 요소이다.

 

가상 스레드가 기존 자바 패러다임에서 적은 변경으로 성능 개선을 기대할 수 있는 기술이지만 앞서 언급했듯이 기존 플랫폼 스레드 기반으로 운영하던 서비스에 가상 스레드를 도입하기 위해서는 추가적인 검증이 필요해 보인다. 자바 개발자 입장에서는 정말 희소식이다. 🙂 
 

Reference

• [Naver D2] Virtual Thread의 기본 개념 이해하기
• [LY] Java 가상 스레드, 깊이 있는 소스 코드 분석과 작동 원리 1편 - 생성과 시작
• [kakaopay] [Project Loom] Virtual Thread에 봄(Spring)은 왔는가
• Virtual Thread란 무엇일까? (1)
• [oracle] virtual thread
• [openJDK wiki] Loom
• [spring io] Embracing Virtual Threads
• [dev.java] Virtual Thread