이 보장은 **Java 메모리 모델(JMM)**의 클래스 초기화와 관련된 happens-before 규칙에서 나옵니다. JVM이 클래스의 정적 필드 또는 메서드에 처음 접근할 때, 먼저 클래스의 초기화 단계를 완료해야 합니다. 이 단계에서는 해당 클래스 객체에 고유한 내부 잠금 하에 정적 초기화자 블록과 필드 할당이 실행됩니다. 따라서 정적 초기화기 내에서 수행된 모든 쓰기 작업 – 예를 들어 싱글톤 인스턴스를 구성하는 작업 – 는 해당 필드를 접근하는 스레드의 다음 읽기와 happens-before 관계를 형성하여, synchronized 키워드나 volatile 선언 없이도 구성된 상태에 대한 완전한 가시성을 보장합니다.
public class ConnectionPool { private ConnectionPool() { // 비용이 많이 드는 TCP 핸드쉐이크 및 스레드 생성 } private static class Holder { static final ConnectionPool INSTANCE = new ConnectionPool(); } public static ConnectionPool getInstance() { return Holder.INSTANCE; // Holder 클래스 초기화를 트리거 } }
문제: 금융 거래 애플리케이션에서는 초기 TCP 핸드쉐이크 및 스레드 생성으로 인해 생성 비용이 많이 드는 ConnectionPool 싱글톤이 필요했지만, 특정 경량 진단 모드에서는 필요하지 않을 수 있었습니다. 조기 초기화는 풀을 사용하지 않을 때도 시작 시 수백 밀리초를 낭비하게 하며, Double-checked locking은 지침 재정렬을 방지하기 위해 volatile 의미론과 순서 장벽을 주의 깊게 처리해야 했습니다.
솔루션 1: 조기 초기화: 이 접근법은 클래스 로드 시 정적 필드를 초기화하며, 이는 구현이 간단하고 JVM에 의해 스레드 안전이 보장됩니다. 그러나 풀에 접근하지 않을 경우 생성 비용을 피하는 요구 사항을 충족하지 않아 진단 모드에서 상당한 자원을 낭비하고 배포 시작 시간을 불필요하게 증가시킵니다.
솔루션 2: 동기화된 접근자: getter를 synchronized로 감싸면 모든 스레드 간의 안전성을 보장하며 코드는 간단합니다. 불행히도, 인스턴스가 존재한 후에도 모든 호출자가 모니터를 획득해야 하므로 고빈도 거래 하중 하에서 심각한 병목 현상을 초래합니다.
솔루션 3: 지연 초기화 홀더: 이것은 static final ConnectionPool 인스턴스를 포함하고 getInstance가 단순히 ConnectionPoolHolder.INSTANCE를 반환하는 비공개 정적 클래스 ConnectionPoolHolder를 정의합니다. 이는 JVM의 지연 클래스 로딩을 활용하며, getInstance가 호출될 때만 홀더 클래스가 초기화되고 클래스 초기화 잠금이 명시적 동기화나 volatile 오버헤드 없이 안전한 출판을 보장합니다.
선택된 솔루션: 팀은 초기화 후 성능이 제로인 비용과 Java 메모리 모델 하에 보장된 안전성을 위해 홀더 이디엄을 선택했으며, 이는 지연 초기화와 런타임 효율성을 완벽히 균형 잡았습니다.
결과: 애플리케이션은 동시 하중 하에서 풀 참조에 대해 서브 마이크로초 접근 지연을 달성하였고, 첫 사용하는 시점까지 무거운 초기화를 지연시켜 진단 모드에서 시작 오버헤드를 없애고 고부하 거래 세션에서 경쟁 조건을 피할 수 있었습니다.
홀더 클래스 초기화 중에 싱글톤 생성자가 예외를 던지면 이후 스레드에는 어떤 일이 발생합니까?
정적 초기화자가 예외를 던지면 JVM은 클래스를 초기화 실패로 표시하고 ExceptionInInitializerError를 발생시킵니다(원인을 포장). 중요하게도, ConnectionPoolHolder에 접근하려고 하는 후속 스레드는 NoClassDefFoundError를 받게 되며, 루트 원인이 일시적일 경우(예: 일시적인 네트워크 비가용성)에도 마찬가지입니다. Double-Checked Locking과 달리 이 패턴은 건너뛰기 블록 내에서 재구성을 시도할 수 없으므로, 클래스는 정의된 ClassLoader의 생명 동안 초기화 실패 상태로 남아 있기 때문에 외부 복구 로직이 필요합니다.
지연 초기화 홀더 패턴을 다중 테넌트 컨테이너 내 인스턴스 범위의 싱글톤에 맞게 수정할 수 있습니까?
아니요. 이 패턴은 철저히 정적 필드와 클래스 수준의 초기화 잠금을 기반으로 합니다. 인스턴스 범위 또는 테넌트 별 싱글톤의 경우 홀더는 테넌트 컨텍스트의 내부 클래스가 될 필요가 있지만 클래스 초기화 잠금은 ClassLoader 단위가 아니라 컨테이너 인스턴스 단위입니다. 이는 테넌트 간의 인스턴스를 공유하게 하여(보안 및 격리 위험)거나 테넌트 인스턴스 내에서 명시적인 동기화를 요구하게 되어 패턴의 비잠금 접근 목적을 무의미하게 만듭니다. 후보자들은 클래스 수준의 지연 로딩과 객체 수준의 지연 로딩을 혼동하는 경우가 많습니다.
이 이디엄은 애플리케이션 서버 환경에서 여러 ClassLoader 계층이 관련될 때 어떻게 작동합니까?
각 ClassLoader는 홀더 클래스의 자체 복사본을 독립적으로 초기화합니다. Tomcat 또는 WildFly에서 싱글톤 클래스가 웹 애플리케이션과 공유 부모 로더 모두에 존재하거나 웹 애플리케이션이 재배포되는 경우(새 ClassLoader 생성), 뚜렷한 인스턴스가 존재하게 됩니다. 이는 JVM 프로세스 전반에 걸쳐 싱글톤 계약을 위반합니다. 이 패턴은 단일 클래스 로딩 네임스페이스 내에서의 스레드 안전성을 보장하지만, 모듈형 환경에서 클래스 로더 격리가 시행되는 경우 전역 JVM 싱글톤 의미론을 제공하지 않으며 이는 중요한 구별 사항입니다.