Java 24의 혁신: 가상 스레드 동기화 블록 핀닝 문제 해결과 성능 향상

목차

• 가상 스레드와 핀닝 문제 소개
• synchronized 블록과 캐리어 스레드 핀닝 현상
• Java 24의 혁신적 해결책: JEP 491
• Java 21과 Java 24 동기화 방식 비교
• 마무리: 가상 스레드의 새로운 시대

가상 스레드와 핀닝 문제 소개

여러분, 자바 개발하면서 동시성 처리로 머리 아팠던 경험 있으시죠? 저도 그랬어요. 특히 Java 21에서 도입된 가상 스레드(Virtual Threads)는 정말 혁신적인 기능이었지만, 한 가지 큰 문제가 있었습니다. 바로 '핀닝(pinning)' 현상이었죠.

그런데... Java 24에서 드디어 이 문제가 해결된다는 소식! JEP 491 「Synchronize Virtual Threads without Pinning」을 통해 동기화 블록에서도 가상 스레드가 캐리어 스레드에 고정되지 않는 혁신적인 변화가 일어났습니다.

이 글에선 '도대체 핀닝이 뭐길래 그렇게 문제였는지', 그리고 'Java 24에서는 이걸 어떻게 해결했는지'에 대해 자세히 알아보려고 합니다. 특히 동시성 프로그래밍을 자주 다루는 개발자분들에겐 정말 반가운 소식일 테니, 함께 살펴봐요!

synchronized 블록과 캐리어 스레드 핀닝 현상

가상 스레드와 핀닝의 개념

먼저 가상 스레드가 뭔지 간단히 복습해볼게요. Java 21에서 정식으로 도입된 가상 스레드는 경량 스레드로, OS 수준의 스레드(플랫폼 스레드)와 달리 JVM에 의해 관리됩니다. 가상 스레드의 핵심 아이디어는 '적은 수의 OS 스레드로 많은 수의 가상 스레드를 효율적으로 실행'하는 것이죠.

가상 스레드는 캐리어 스레드(Carrier Thread)라는 실제 OS 스레드 위에서 실행됩니다. 가상 스레드가 I/O 작업처럼 블로킹 작업을 만나면, 해당 가상 스레드는 캐리어 스레드에서 '언마운트(unmount)'되고, 캐리어 스레드는 다른 가상 스레드를 실행할 수 있게 됩니다.

그런데 문제는 바로 여기서 발생했어요. Java 21에서는 가상 스레드가 synchronized 블록이나 메서드 내부에 있을 때 언마운트가 불가능했습니다. 이걸 '핀닝(pinning)'이라고 해요. 쉽게 말해, 가상 스레드가 synchronized 블록에 들어가면 캐리어 스레드에 '고정'되어버리는 거죠.

"핀닝은 가상 스레드가 언마운트되는 것을 방지합니다. 결과적으로 read 메서드는 가상 스레드뿐만 아니라 캐리어 스레드, 그리고 기본 OS 스레드까지 블로킹하게 됩니다." - JEP 491 명세서

왜 핀닝이 문제였을까?

핀닝이 왜 문제였냐구요? 아... 정말 큰 문제였습니다. 한번 예를 들어볼게요.

synchronized (lock) {
    // 여기서 I/O 작업이나 네트워크 요청같은 블로킹 작업 수행
    response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());
    // 처리 로직...
}

위 코드처럼 synchronized 블록 안에서 블로킹 I/O 작업을 수행한다고 생각해보세요. Java 21에서는 이 가상 스레드가 캐리어 스레드에 핀닝되어서, 네트워크 응답을 기다리는 동안 해당 캐리어 스레드는 아무것도 못하고 그냥 기다리게 됩니다. 만약 수천 개의 가상 스레드가 이런 상태라면? 사실상 모든 캐리어 스레드가 블로킹되어 시스템이 멈춰버릴 수도 있습니다.

⚠️ 주의

Java 21에서 가상 스레드를 사용할 때는 synchronized 블록 내에서 블로킹 작업을 수행하지 않도록 주의해야 했습니다. 이런 제약은 기존 코드를 가상 스레드로 마이그레이션하는 데 큰 장벽이 되었죠.

솔직히 말하자면, 이 문제 때문에 많은 개발자들이 synchronized 대신 ReentrantLock 같은 java.util.concurrent 패키지의 락을 사용하도록 코드를 수정했어요. 이런 락은 가상 스레드를 핀닝하지 않거든요. 근데 이거... 기존 코드 전부 바꾸는 건 엄청난 작업이잖아요. 진짜 골치 아픈 문제였죠.

Java 24의 혁신적 해결책: JEP 491

그래서 Java 24에서는 이 문제를 어떻게 해결했을까요? JEP 491을 통해 synchronized 키워드가 가상 스레드를 핀닝하지 않도록 개선했습니다. 이게 어떻게 가능해진 건지 자세히 살펴봅시다.

Java 24의 새로운 동기화 매커니즘

Java 24에서는 synchronized 블록이나 메서드 내부에서도 가상 스레드가 캐리어 스레드에서 언마운트될 수 있도록 JVM 내부 구현을 변경했습니다. 이건 정말 획기적인 변화인데요, 덕분에 기존 synchronized를 사용하는 코드도 가상 스레드의 장점을 온전히 활용할 수 있게 되었습니다.

📝 메모

Java 24의 새 구현에서는 가상 스레드가 모니터를 획득한 상태에서 블로킹 작업을 만나면, 모니터 소유권을 유지하면서도 캐리어 스레드에서 언마운트됩니다. 이렇게 하면 다른 가상 스레드들이 그 캐리어 스레드를 사용할 수 있게 되죠.

이 변경으로 기존 코드를 수정하지 않고도 가상 스레드의 확장성 이점을 최대한 활용할 수 있게 되었습니다. 음... 뭐랄까, 정말 기다려온 기능이랄까요? 개발자들이 ReentrantLock으로 바꾸느라 고생했던 시간들이 좀 아깝긴 하네요. 😅

하지만, 아직 완벽하진 않습니다. JEP 491에서도 언급했듯이, 몇 가지 특수한 경우에는 여전히 핀닝이 발생할 수 있어요. 예를 들면:

• 네이티브 메서드 실행 중일 때
• 외부 함수(foreign function) 호출 중일 때
• JNI 코드 실행 중일 때

그래도 일반적인 Java 코드에서 synchronized를 사용할 때는 이제 핀닝 걱정 없이 가상 스레드를 활용할 수 있게 되었으니, 큰 발전이라고 할 수 있겠죠!

Java 21과 Java 24 동기화 방식 비교

코드 예제와 함께 Java 21과 Java 24에서의 동기화 방식 차이를 비교해볼게요.

Java 21에서는 다음과 같은 코드가 문제였습니다:

// Java 21에서 문제가 되는 코드
shared class SharedResource {
    private final Object lock = new Object();
    
    public String fetchData() {
        synchronized (lock) {
            // 여기서 I/O 작업 - 핀닝 발생!
            return httpClient.send(request, HttpResponse.BodyHandlers.ofString()).body();
        }
    }
}

위 코드는 Java 21에서 가상 스레드 핀닝을 일으켜 확장성 문제를 야기했습니다. 그래서 개발자들은 다음과 같이 코드를 변경해야 했죠:

// Java 21에서 권장되는 해결책
import java.util.concurrent.locks.ReentrantLock;

class SharedResource {
    private final ReentrantLock lock = new ReentrantLock();
    
    public String fetchData() {
        lock.lock();
        try {
            // 여기서 I/O 작업 - 핀닝 발생하지 않음
            return httpClient.send(request, HttpResponse.BodyHandlers.ofString()).body();
        } finally {
            lock.unlock();
        }
    }
}

하지만 Java 24에서는 첫 번째 코드도 문제없이 사용할 수 있게 되었습니다! synchronized 블록 내에서 I/O 작업을 수행해도 가상 스레드가 핀닝되지 않기 때문이죠.

Java 24에서는 기존에 작성된 수많은 synchronized 코드들이 가상 스레드에서도 효율적으로 동작할 수 있게 되었습니다. 이는 가상 스레드 도입의 진입 장벽을 크게 낮추는 중요한 발전입니다.

마무리: 가상 스레드의 새로운 시대

Java 24의 JEP 491은 가상 스레드의 활용성을 크게 향상시킨 혁신적인 개선입니다. 기존 코드베이스를 대대적으로 수정하지 않고도 가상 스레드의 장점을 활용할 수 있게 되었죠. 이는 Java의 동시성 모델을 현대화하고, 더 효율적인 서버 애플리케이션 개발을 가능하게 합니다.

물론 아직 몇 가지 제한사항이 남아있긴 하지만, Java 개발팀은 지속적으로 이러한 문제들을 해결해 나가고 있습니다. 앞으로도 Java의 진화는 계속될 것이고, 우리 개발자들은 그 혜택을 누릴 수 있을 겁니다.

Q Java 24에서도 여전히 핀닝이 발생하는 경우는 언제인가요?

synchronized 블록 안에서도 핀닝이 사라졌다고 하는데, 여전히 주의해야 할 상황이 있을까요?

A 일부 상황에서는 여전히 핀닝이 발생합니다

네이티브 메서드 호출, JNI 코드 실행, 외부 함수(foreign function) 호출 등의 상황에서는 여전히 가상 스레드 핀닝이 발생할 수 있습니다. 이런 경우에는 가능한 synchronized 블록 바깥에서 이러한 작업을 수행하거나, 해당 작업을 별도의 스레드에서 실행하는 것이 좋습니다.

Java 24는 아직 출시 전이지만, 이번 개선사항은 가상 스레드를 활용한 고성능 애플리케이션 개발에 큰 도움이 될 것입니다. 특히 기존에 synchronized를 많이 사용하던 코드베이스에서 가상 스레드로의 전환을 고려하고 계셨다면, Java 24로의 업그레이드를 적극 검토해보시는 걸 추천드립니다!

여러분의 Java 개발 경험에 이 정보가 도움이 되었기를 바랍니다. 혹시 가상 스레드나 Java 24에 대해 더 궁금한 점이 있으시면 언제든 댓글로 남겨주세요. 함께 이야기 나눠봐요! 😊