Java 스레드의 발전 과정과 가상 스레드 (Virtual Thread)
용어 정리
스레드 분류
커널 스레드
• OS 커널에 의해 생성되고 관리되는 스레드
• OS 스레드, 네이티브 스레드 라고도 불림
유저 스레드
• 커널 스레드를 프로그래밍 레벨에서 추상화한 스레드
• OS가 관리하는 커널스레드와 매핑되어 동작
스레드매핑모델
many-to-one model
• 다수의유저스레드를하나의커널스레드와매핑
one-to-one model
• 하나의유저스레드를하나의커널스레드와매핑
many-to-many model
• 다수의유저스레드를다수의커널스레드가처리
• 별도의스케줄러로관리필요
Java 스레드의 발전 과정
Jdk 1.1
many-to-one model
• CPU Core가 1개인 환경에서 설계된 방식, 그린 스레드라는 명칭의 유저 스레드 사용
• 단점: 커널스레드가 Blocking 되면 모든 유저 스레드가 작업을 하지 못한다.
Jdk 1.3
one-to-one model
• OS스레드를Wrapping한플랫폼스레드를활용
• 단점: I/O 작업 시 Blocking 되며 Blocking 시 Context Switching 부담
• 단점: 스레드 생성 비용이 크다. (스레드풀을 활용하는 이유, 차지하는 메모리 크기가 크다.)
플랫폼 스레드 I/O 블로킹을 고려한 대안
Reactive Programming
• 여러 이벤트 루프를 활용한 Non-Blocking 모델을 활용, calback과 이벤트 기반 처리
• 단점: Blocking I/O 기반 라이브러리 활용의 어려움, 복잡한 코드 구조와 러닝커브
코루틴(Spring 생태계는Kotlin 한정)
• 여러 루틴이 협력적으로 실행을 제어하는 패턴
• I/O 작업을 기다리는 동안 다른 작업을 처리할수 있어 CPU idle-time 최소화를 도움
• 단점: 코드 제어 흐름을 이해하기 어려운 경우 발생, 코루틴에 한정된 문법 활용 필요
해결하고 싶은 문제점
Jdk1.3 부터 사용 가능한 플랫폼 스레드
• 단점: Blocking I/O 활용 -> 높은I/O 처리량 필요 시 부담
Reactive Programming, 코루틴
• 단점: 특정적인 문법과 제약->개발/유지보수 어려움
가상 스레드 (Virtual Thread)
many-to-many model
• Project Loom으로 시작된 경량 스레드 모델
• Jdk21에 정식 feature로 추가
• [높은 I/O 처리량시부담, 개발+유지보수 어려움] 문제 해결
스레드 모델 오버헤드 비교
| Thread 1개 기준 (최댓값) | Thread | Virtual Thread |
| 메모리 사용량 | ~ 2MB | ~ 50KB |
| 생성 시간 | ~ 1ms | ~ 10 μs |
| 컨텍스트 스위칭 시간 | ~ 100 μs | ~ 10 μs |
특징
1. 스레드 생성 비용과 컨텍스트 스위칭 비용이 낮음
-> OS가 아닌 JVM이 지원하기 때문
2. JVM 내 스레드 스케줄링을 통해 NonBlocking I/O 지원
-> Blocking 시 스레드가 대기하지 않고 작업 정보를 저장해두고 다른 작업을 처리하다 Blocking이 끝나면 재개
3. 기존 스레드를 상속하여 코드 호환
-> 기술에 한정된 문법이나 큰 수정 없이 사용 가능하다는 장점
전체 구조
컨텍스트 스위칭 비교
플랫폼 스레드 방식
OS Level Context Switching
가상 스레드 방식
JVM Level Context Switching
가상 스레드의 스케줄러
Fork Join Pool (Work Steal Queue 활용)
• 작업 처리 요청(submit)시 선점한 스레드의 Queue에 가상 스레드 저장
• 플랫폼 스레드(캐리어 스레드)는 각자의 Queue에 들어간 작업을 처리
• 만약 본인의 Queue의 모든 작업을 처리했다면 다른 Queue에서 작업을 훔쳐와서(Steal) 처리
동작 과정
용어 정리
• Continuation: 가상 스레드가 실행해야 할 작업과 작업에 대한 진행 단계 정보
• StackChunk: Blocking 시 Heap에 저장되는 실행 정보(스택 프레임)
• 캐리어 스레드: 작업을 수행하는 플랫폼 스레드로 각자 Queue를 가짐
• 가상 스레드는 Queue에 저장되어 캐리어 스레드와 매핑되어 실행
• 실행이 끝나면 캐리어 스레드는 다른 가상 스레드와 매핑
• 실행중 Blocking 되면 StackChunk를 Heap에 저장, 캐리어 스레드를 다른 가상 스레드에게 양보
• Blocking이 끝나면 Heap에서 StackChunk를 불러와 중단지점부터 재개
기존 스레드를 상속하여 코드 호환
• 큰 수정 없이 활용 가능하며, SpringBoot는 application.yml 에 전역 설정 가능한 옵션 제공
도입시주의사항
• 캐리어 스레드를 Block 하는 경우(synchronized 등)의 Pin 이슈로 Virtual Thread 활용 불가 (Jdk24 이후로는 이슈 없음)
• 라이브러리 내부 코드가 synchronized를 사용한다면 병목 가능성
• 스레드풀 방식으로 활용하지 않는 것을 권장-> 생성 비용이 저렴하기 때문
• CPU Bound 작업의 경우 결국 Carrier Thread 위에서 동작하므로 Virtual Thread 활용은 성능 낭비
• 배압(BackPressure) 조절 기능이 없기 때문에 과도한 생성으로 인한 과부하를 주의해야 함
학습하며 발생한 의문과 해답
아래 의문들이 들었으며, 다음 포스트에 정리해두도록 하겠다:
https://ohksj77.tistory.com/282
Java 가상 스레드 (Virtual Thread) 에 관한 오해 짚고 넘어가기
목차왜 virtual thread를 many-to-many 모델이라고 부르는가?ForkJoinPool이 내부적으로 어떻게 활용되는가?왜 virtual thread는 기존 플랫폼 스레드보다 메모리 덜 차지하는가?가상스레드를 어느정도로 생성
ohksj77.tistory.com
- 왜 virtual thread를 many-to-many 모델이라고 부르는가?
- ForkJoinPool이 내부적으로 어떻게 활용되는가?
- 왜 virtual thread는 기존 플랫폼 스레드보다 메모리 덜 차지하는가?
- 가상스레드를 어느정도로 생성했을 때 위험하며, 어떻게 방지할 수 있는가?
- virtual thread pool을 설정하지 않는 게 좋은 이유?
- 가상스레드 활용 시 carrier thread(platform thread) 설정은 어떻게 할 것인가?
- 기존 platform thread는 왜 pool로 설정하였는가?
- virtual thread가 생성 되어지는 위치?
- virtual thread가 실행 되어지며 갖는 transaction, context는 어떻게 저장 되어져서 다른 carrier thread에서 실행 되어져도 데이터 일관성을 지킬 수 있는가?
- virtual thread 와 spring 과의 연동 되어지는 내부 과정?
- 실제로 spring 프레임워크와 연동 하였을 때 이슈가 없는가?
- 기존 thread와 구조가 달라졌는데 Spring도 업데이트되었는지 혹은 반영을 위한 업데이트가 필요 없었는지?
- virtual thread 사용시에 synchronized를 사용하면 이슈가 발생 하는 이유?
- 다른 주요 라이브러리 및 프레임워크에서 이슈가 발생할 수 있는 예시는 어떤게 있나?
- virtual thread 가 성능을 높이기 위한 기술인가?
- continuation이란 무엇이며 기존 플랫폼 스레드의 스택 구조와의 차이는 어떠한가?
- jdk24 부터는 pin 이슈가 어떻게 해결되었으며 완벽히 pin 이슈가 해결된 것인가?
참고한 레퍼런스, 이미지 출처
https://velog.io/@suhongkim98/자바-언어의-태생적-한계와-극복을-위한-발전-과정-스레드편 https://techblog.lycorp.co.jp/ko/about-java-virtual-thread-1
https://xpmxf4.tistory.com/119
https://techblog.woowahan.com/15398/