🏳️‍🌈 [궁금한점]

• Kafka, Trino, Spark에서 사용하는 JDK를 통일해야 할까
• JDK 어느 버전을 선택해야 할까

---

🔗[목차]

• JDK 주요 버전 비교
  • JDK 버전
  • Lakehouse에 적합한 JDK 버전
  • JDK 배포판
  • Lakehouse 구성요소별 JDK 21 호환성
• JDK 21이 고성능인 이유
  • Virtual Threads (가상 스레드, Project Loom)
  • GC 개선 (Garbage Collector 최적화)
  • 기타 JVM 성능 최적화
  • Native Memory Tracking, CDS (Class Data Sharing) 개선
  • 최적의 컨테이너 호환성
• Lakehouse에서 JDK 선정
• Virtual Thread
  • 기존 Platform Thread의 한계
  • Virtual Thread의 원리
  • virtual thread 사용 유의점
    • Block이 일어나는 네이티브 호출은 문제 소지
    • Thread-local, InheritableThreadLocal 관련 동작 차이
    • 디버깅/모니터링 도구 호환성 문제
    • Virtual Thread는 CPU-bound에는 큰 도움 안 됨
    • ExecutorService가 기존 코드와 충돌할 수 있음

JDK 주요 버전 비교

JDK 버전

버전	출시일	LTS 여부	공식 지원 종료	주요 특징	권장 환경
JDK 8	2014-03	Y	2030 (Oracle 유료)	널리 사용됨, 많은 시스템과 호환	레거시 시스템, 보수적 운영 환경
JDK 11	2018-09	Y	2026-09 (무료), 2032 (유료)	모듈 시스템(JPMS), ZGC, TLS 1.3	안정적 운영 시스템, 마이그레이션 완료 환경
JDK 17	2021-09	Y	2029-09 (무료), 2031+ (유료)	Sealed classes, pattern matching, 성능 개선	신규 서비스, 컨테이너 기반 배포
JDK 21	2023-09	Y	2031-09 (무료)	Virtual threads, record patterns, 강화된 GC	고성능 마이크로서비스, 최신 JVM 기능 활용
JDK 22	2024-03	N (비LTS)	6개월 지원	Preview 기능 실험용	테스트, 연구용

Lakehouse에 적합한 JDK 버전

용도	추천 JDK 버전	이유
Spark (3.x ~ 4.x)	JDK 8 또는 11	안정성과 호환성 면에서 가장 널리 사용됨. 일부 최신 버전은 JDK 17도 지원하지만, 대부분 11이 가장 안전함.
Trino (>= 380)	JDK 17	Trino는 JDK 17 이상을 공식적으로 권장함. JDK 21에서도 잘 작동함.
Iceberg	JDK 11 이상	Iceberg는 Spark 또는 Trino에 따라 다름. Spark와 함께 쓰면 Spark 기준을 따라야 함.
Flink	JDK 8 또는 11	JDK 17도 일부 지원되지만 보수적으로는 8 또는 11이 일반적.
Hive Metastore	JDK 8 또는 11	오래된 코드베이스이므로 JDK 11까지가 가장 안전함.
Kafka	JDK 11 (최신 버전은 JDK 17도 가능)	Kafka도 11에서 안정적으로 동작. 일부 최신 릴리스는 JDK 17까지도 지원.

JDK 배포판

배포판	설명
Temurin (Adoptium)	가장 널리 사용되고 안정적인 오픈소스 JDK. 기업 및 오픈소스 프로젝트에서 광범위하게 사용됨.
OpenJDK (패키지 매니저 설치)	공식 JDK. 다만 일부 패키지는 업데이트가 느릴 수 있음.
Amazon Corretto	AWS 기반 프로젝트에서 사용 시 추천됨. 장기 지원(LTS) 제공.
Zulu OpenJDK (Azul)	다양한 플랫폼에 대한 폭넓은 지원.

Lakehouse 구성요소별 JDK 21 호환성

컴포넌트	JDK 21 지원 현황 (2025 기준)	주의사항
Trino (v466)	공식적으로 JDK 21 지원	Trino는 빠르게 최신 JDK 지원함.
Apache Iceberg	Spark 기반이라면 Spark 기준 따름	Spark 3.5+에서 JDK 21 일부 지원. Spark < 3.5는 지원 불확실.
Apache Spark	Spark 3.5 이상 일부 호환, 안정성 이슈 존재	아직 실무에서 Spark+JDK 21 조합은 드묾.
Hive Metastore	공식적으로 JDK 11 이하 권장	오래된 코드베이스. JDK 21에서 예기치 않은 에러 발생 가능.
Apache Flink	JDK 21은 실험적 수준	대부분 JDK 11까지 안정.
Kafka	JDK 17까지 광범위 검증, 21은 실험적	일부 JDK 21 문제 보고됨.

JDK 21이 고성능인 이유

JDK 21이 고성능인 이유는 여러 가지 JVM 수준의 혁신적 기능과 언어 개선이 포함되었기 때문이다. 특히 대규모 병렬 처리가 필요한 현대적 서비스 환경(API 서버, 마이크로서비스, Kafka 소비자 등)에 매우 잘 맞다.

Virtual Threads (가상 스레드, Project Loom)

• 가장 큰 변화, 기존 스레드 모델을 혁신적으로 개선
• 기존 java.lang.Thread는 OS 커널 스레드에 매핑되어 수천 개 이상 생성 시 성능 병목 발생
• Virtual Thread는 JVM 내부 스케줄링 기반 → 수백만 개 생성 가능
• 컨텍스트 스위칭 오버헤드 감소, Thread starvation 현상 감소
• I/O 중심 애플리케이션 (예: HTTP 서버, DB 연동, Kafka consumer)에서 Thread 수를 획기적으로 줄여줌
• 기존 Thread로 1만 개 요청 처리 시 CPU 사용률 80%+, Virtual Thread로 1만 개 처리 시 CPU 30% 수준, TPS 2~4배 상승

GC 개선 (Garbage Collector 최적화)

• G1 GC: 기본 GC로 설정되며, pause time 예측 가능
• ZGC: low-latency GC로 10ms 이내 GC pause 제공
• Shenandoah: Red Hat 지원, 병행 처리 강화

G1/ZGC는 JDK 21에서 안정성과 성능이 극대화됨:GC throughput 5~10% 증가, GC pause time은 더 짧아짐 (특히 ZGC)

기타 JVM 성능 최적화

• JIT Compiler 개선 (C2): 루프 최적화, 메서드 인라이닝 향상
• Escape Analysis 향상: 객체를 힙이 아닌 스택에 할당 → GC 부담 감소
• String Templates (Preview): 문자열 결합 성능 향상
• Pattern Matching과 같은 언어적 구조는 코드의 효율성과 명확성 증가

Native Memory Tracking, CDS (Class Data Sharing) 개선

• CDS: 공통 클래스 영역을 공유하여 애플리케이션 시작 시간 단축
• Native Memory Tracking: 메모리 누수 파악과 튜닝에 유리

최적의 컨테이너 호환성

JDK 21은 컨테이너 런타임(Kubernetes 등)의 CPU/Memory limits를 정확히 감지하고 JVM 파라미터를 자동 조정

예: -XX:+UseContainerSupport가 자동 활성화

컨테이너 최적화된 GC 동작과 CRaC(Coordinated Restore at Checkpoint) 등 최신 기능 일부도 지원 예정

Lakehouse에서 JDK 선정

구성 요소	JDK 버전	GC 추천	비고
Trino	JDK 17	G1GC	안정성과 성능 균형. ZGC는 실험적으로 가능
Spark	JDK 17	G1GC	Structured Streaming에서 안정적 동작. 특히 IcebergSink
Iceberg	N/A (라이브러리)	JVM 기반 앱에 따름	Spark/Trino가 관리
MinIO	Go 언어 기반	JVM 아님	JDK/GC와 무관

Virtual Thread

Virtual Thread는 Java 19부터 프리뷰로 도입되었고, Java 21에서 정식 기능으로 채택된 lightweight thread이다. 기존의 Platform Thread와는 다르게, OS 스레드에 직접 매핑되지 않아서 수천, 수만 개의 스레드를 생성해도 성능에 큰 영향을 주지 않는다.

구분 Platform Thread Virtual Thread
기반 OS 스레드 Java 스케줄러에 의해 관리
생성 비용 높음 낮음
동시 실행 수 제한적 수천~수만 개도 가능
목적 전통적 병렬 처리 대규모 동시성 처리 (ex. 웹서버 요청 핸들링 등)

public class ManyVirtualThreads {
    public static void main(String[] args) throws InterruptedException {
        int threadCount = 10_000;

        for (int i = 0; i < threadCount; i++) {
            Thread.startVirtualThread(() -> {
                try {
                    Thread.sleep(100); // 비동기 처리 시 유용
                    System.out.println("Thread: " + Thread.currentThread());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }

        Thread.sleep(2000); // 전체 실행 대기
    }
}

Virtual thread는 블로킹 IO보다는 비동기/논블로킹 IO와 함께 사용할 때 더 큰 효과를 본다.synchronized 같은 기존 락 메커니즘은 virtual thread의 장점을 줄일 수 있다.

Java가 운영체제(OS) 수준에서의 스레드 관리에서 JVM 내부 스케줄링으로 바뀌었다.

기존 Platform Thread의 한계

Platform Thread는 OS 스레드 1:1 매핑 구조이다. new Thread()로 만들면 JVM이 OS에게 스레드를 요청해서 커널 리소스가 할당된다.

이로 인해 다음과 같은 문제점이 생긴다.

• 생성/제거 비용이 비쌈 (시스템 콜이 필요)
• 스레드 수 제한이 있음 (몇 천 개 수준이 한계)
• 블로킹 I/O나 Thread.sleep()은 OS 스레드를 점유함 (낭비!)

Virtual Thread의 원리

Virtual Thread는 JVM 내부의 lightweight 스레드이다. OS 스레드에 직접 연결되지 않고, JVM이 몇 개의 고정된 carrier thread를 통해 많은 virtual thread를 multiplexing 해준다.

• Java Continuations (Continuation Stack):
  실행 중이던 Virtual Thread의 스택 프레임을 저장하고 중단할 수 있음.
  즉, Thread.sleep() 하면 스택 저장하고, carrier thread는 다른 virtual thread 처리하러 감.

• User-mode Scheduling:
  OS 대신 JVM이 thread 전환을 담당 → context switching이 매우 빠름.

• Non-blocking APIs와의 통합:
  기존 blocking I/O API (sleep, Socket.read)도 내부적으로는 JVM이 알아서 virtual thread friendly하게 동작시킴.

virtual thread 사용 유의점

Block이 일어나는 네이티브 호출은 문제 소지

Virtual Thread는 Java 코드 내의 블로킹은 감지하고 회피할 수 있지만, JNI 호출, 파일 I/O, native socket, 동기 JDBC 등은 OS 스레드 수준에서 블로킹되어 Virtual Thread의 장점이 사라진다.

virtualThreadExecutor.submit(() -> {
    // 오래 걸리는 native 블로킹 함수 호출 시 -> 실제 OS thread가 점유됨
    someBlockingNativeFunction(); 
});

가능하면 비동기 I/O 사용하도록 한다.

Thread-local, InheritableThreadLocal 관련 동작 차이

Virtual Thread는 thread-local을 성능을 위해 복사하지 않고 기본적으로 격리하므로 예상과 다른 결과가 나올 수 있다.
ThreadLocal 대신 ScopedValue 사용한다. (Java 21부터 프리뷰)

디버깅/모니터링 도구 호환성 문제

기존 APM, thread dump 도구들이 수만 개의 Virtual Thread를 감당 못 하거나 정확한 정보 제공 못한다.
최신 도구 jcmd, jfr 등으로 분석한다.

Virtual Thread는 CPU-bound에는 큰 도움 안 됨

Virtual Thread는 I/O-bound 작업 최적화에 탁월하나 CPU-bound 작업은 병렬 스레드 개수 늘린다고 성능이 오르지 않음 (오히려 컨텍스트 스위칭 비용 증가 가능)

ExecutorService가 기존 코드와 충돌할 수 있음

• 일부 프레임워크나 라이브러리에서 Executors.newCachedThreadPool()을 Virtual Thread로 바꿨을 때, 스레드가 무제한 생성되어 시스템 과부하 발생 가능성 있다.
• Executors.newVirtualThreadPerTaskExecutor() 사용 시 부하를 고려해 제한 설정 필요