Java 1.1에서는 초기화자 없이 final로 선언된 변수인 blank final 변수를 도입하여 즉각적인 할당을 강제하지 않고 유연한 불변 패턴을 지원했습니다. 근본적인 문제는 이러한 필드가 사용되기 전에 모든 가능한 실행 경로에서 정확히 한 번만 할당되도록 보장하는 것이며, 초기화를 우회할 수 있는 try-catch 블록, 분기 로직 및 조기 반환으로 복잡해집니다. 이를 해결하기 위해 컴파일러는 제어 흐름 그래프(CFG)에서 Definite Assignment (DA) 분석을 수행하여 각 프로그램 포인트에서 반드시 할당된 변수 집합을 추적합니다. 그리고 final 변수에 대해 필드가 두 번 작성되지 않도록 보장하기 위해 Definite Unassignment (DU) 분석도 수행합니다. 바이트코드 검증기는 클래스 로딩 시 StackMapTable 속성과 유형 검사를 통해 이러한 제약 조건을 시행하여 어떤 명령도 확실히 초기화되지 않은 변수를 읽지 않도록 보장합니다.
재무 서비스 팀은 생성자 내에서 외부 서비스 호출을 통해 생성된 final UUID tradeId를 가진 ImmutableTrade 클래스를 만들었습니다. 생성자는 이 호출을 처리하기 위해 try-catch로 감싸고 ServiceUnavailableException을 처리하면서 오류를 기록하고 다시 던졌지만, catch 블록에서 tradeId를 할당하지 않아 컴파일러의 Definite Assignment 분석이 예외 경로가 final 필드를 초기화하지 않은 것을 감지하여 컴파일 오류가 발생했습니다.
제안된 해결책 중 하나는 catch 블록에서 tradeId를 null로 초기화하는 것이었지만, 이는 모든 ImmutableTrade는 유효한 식별자를 가져야 한다는 비즈니스 불변을 위반하여, 하류에서 NullPointerException이 발생할 수 있으며 final 필드의 보장을 무시하게 됩니다. 또 다른 접근 방식은 할당 상태를 추적하기 위해 부울 플래그를 사용하는 것이었지만, 이는 가변 상태와 불필요한 복잡성을 추가하여 팀이 달성하고자 했던 불변성과 스레드 안전성을 저해했습니다. 팀은 궁극적으로 정적 팩토리 패턴으로 리팩토링하기로 결정하여 서비스를 외부에서 호출하고 결과 UUID를 개인 생성자에 전달하여 필드가 유효한 값으로 정확히 한 번 할당되도록 보장했습니다.
이 접근 방식은 더미 값을 요구하지 않고도 컴파일러의 엄격한 DA 분석을 만족시켰으며 클래스의 계약적 불변성을 유지하면서 서비스 결과의 사전 검증 및 캐싱을 가능하게 했습니다. 결과적으로 생성된 코드베이스는 컴파일과 철저한 스트레스 테스트를 통과했으며, 정해진 할당 규칙을 준수하는 것이 생산 환경에서 NullPointerException 문제를 예방하고 ImmutableTrade 객체를 동시 스레드 간에 안전하게 공유할 수 있도록 했음을 입증했습니다.
반사가 생성 후 final 필드를 수정할 수 있으며 이러한 변경이 다른 코드에 보이지 않을 수 있는 이유는 무엇인가요?
반사는 Field#setAccessible(true) 및 set()을 사용하여 인스턴스 final 필드를 수정할 수 있지만, 컴파일 타임 상수로 초기화된 static final 필드는 컴파일러에 의해 클라이언트 바이트코드에 리터럴 값으로 인라인 처리됩니다. 따라서 이러한 상수에 대한 반사 변경은 이미 컴파일된 클래스에서는 보이지 않으며, 클래스는 상수 풀 항목을 참조하고 필드를 참조하지 않습니다. 또한, JVM은 최적화를 위해 진정한 final 필드를 불변으로 처리하므로 VarHandle을 사용한 private lookup 또는 Unsafe로 수정을 강제해야 하며, 그럼에도 불구하고 CPU 캐시는 명시적인 메모리 장벽 없이 변경을 관찰하지 못할 수 있어 미세한 가시성 버그가 발생할 수 있습니다.
구성 중 'this' 참조가 탈출하는 것이 final 필드의 확정 할당 보장과 어떻게 상호 작용하나요?
DA 분석이 final 필드가 생성자 반환 전에 할당되었음을 확인하더라도, 생성 중에 다른 스레드에 this를 게시(예: 리스너 또는 레지스트리를 통해)하면 다른 스레드가 기본값(0/null)을 관찰할 수 있는 경쟁 조건이 발생합니다. Java 메모리 모델은 생성자가 완료된 후 모든 스레드가 final 필드의 값을 올바르게 보는 것을 보장하지만, 생성 중에는 그러한 보장을 제공하지 않습니다. 따라서, 확정 할당은 단일 할당을 보장하는 정적 컴파일 타임 속성인 반면, 안전한 게시를 위해서는 모든 final 필드가 저장되기 전에 this가 생성자를 벗어나는 것을 방지해야 합니다.
컴파일러가 루프 내에서 빈 final 필드에 대한 할당을 거부하는 이유는 무엇인가요? 논리적으로 단 한번 실행된다고 구상되는 경우에도
컴파일러는 보수적인 정적 분석을 수행하며 루프가 정확히 한 번 실행된다고 증명할 수 없거나 0번 반복되지 않는다고 단언할 수 없습니다. 루프는 DA 추적을 복잡하게 만드는 제어 흐름 그래프에 역엣지를 도입합니다. final 필드는 정확히 한 번 할당되어야 하므로 다중 반복(다중 할당) 또는 0회 반복(할당 없음)의 가능성은 빈 final에 필요한 Definite Unassignment 불변성을 위반합니다. 결과적으로, 컴파일러는 빈 final에 대한 할당이 루프 외부 또는 명확한 단일 할당 의미를 가진 분기 내에서 발생해야 하며, 사람이 논리적으로 검증할 수 있지만 CFG가 보장할 수 없는 코드는 거부됩니다.