레코드 클래스는 구성 필드를 final로 암시적으로 선언하여 생성 이후의 변형을 금지합니다. 컴팩트 생성자를 사용할 때(형식 매개변수 목록을 생략) Java 컴파일러는 this.component = ...를 통한 명시적인 필드 할당을 금지합니다. 이는 생성자 본문 실행 직후에 할당 바이트코드를 자동으로 주입하기 때문입니다. 이 설계는 개발자가 필드 대신 매개변수 변수를 스스로 재할당하도록 강제합니다(예: component = Objects.requireNonNull(component)). 따라서 방어적 복사가 변경 가능한 구성 요소에 대해 필수적이 됩니다. 레코드가 참조를 저장하기 때문에 컴팩트 생성자 내에서 변경 가능한 인수를 복제하지 않으면 외부 수정이 레코드의 불변성 보장을 깨뜨릴 수 있습니다.
고빈도 거래 플랫폼 개발 중 아키텍처 팀은 레코드 클래스를 채택하여 BigDecimal 가격과 java.util.Date 타임스탬프가 포함된 불변의 시장 데이터 틱을 표현했습니다. Date의 가변성은 중대한 취약성을 제시했습니다. 프로듀서 스레드가 레코드 인스턴스화 후 타임스탬프 객체를 수정할 수 있는 경합 조건이 발생할 수 있어 감사 추적이 손상될 수 있습니다.
이 노출을 완화하기 위해 세 가지 접근법이 고려되었습니다. 첫 번째 전략은 불변의 시간 유형인 java.time.Instant로 마이그레이션하는 것이었습니다. 이 방법은 방어적 복사 오버헤드를 제거하고 현대 Java 시간 API와 일치했지만, Date 객체를 직렬화하는 기존 미들웨어 구성 요소의 대규모 리팩토링을 필요로 하여 수용할 수 없는 전달 위험을 초래했습니다.
두 번째 옵션은 정적 공장 메서드를 사용하여 방어적 복사를 수행한 후 표준 생성자에 위임하는 것이었습니다. 이 접근법은 캡슐화를 유지했지만, 레코드의 고유한 간결한 문법과 자동 구조적 동등성 이점을 포기하였고, 추가적으로 표준 생성자 패턴을 기대하는 역직렬화 프레임워크를 복잡하게 만들었습니다.
마지막 솔루션은 입력을 검증하고 방어 복제본을 만들기 위해 컴팩트 생성자를 사용하는 것이었습니다: timestamp = (Date) timestamp.clone();. 이는 컴파일러의 암시적 필드 할당을 이용하여 복사를 저장하고 원래 참조는 저장하지 않음으로써 레코드 의미를 훼손하지 않고 스레드 안전성을 보장했습니다.
이 구현은 시간 조작 공격을 성공적으로 방지했으며, 수백만 개의 동시 거래가 포함된 후속 스트레스 테스트에서 데이터 부패 사고를 제로로 유지했습니다.
왜 컴파일러는 일반 생성자에서는 허용되지만 컴팩트 생성자 내에서 명시적 this.field 할당을 거부하는가?
Java 언어 사양은 컴팩트 생성자를 표준 생성자로 확장되도록 정의하고 컴파일러가 매개변수 목록을 합성하고 필드 할당을 추가합니다. 레코드 구성 요소는 암시적으로 final이므로 컴팩트 생성자 본문은 필드가 "확실히 할당되지 않은" 상태에서 실행됩니다. 명시적 this.field 할당은 final 변수에 대한 두 번째 할당으로 간주되어 확실한 할당 규칙을 위반하게 됩니다. 반면 매개변수 변수를 재할당하는 것은 암시적 할당을 가리므로 허용됩니다.
레코드의 컴팩트 생성자에서 방어적 복사가 ObjectInputStream을 사용할 때 역직렬화 공격으로부터 어떻게 안전을 지키는가?
전통적인 Serializable 클래스와 달리, JVM은 Unsafe 할당을 통해 인스턴스화하고 반사 또는 readObject 메서드를 통해 채웁니다. 역직렬화된 레코드는 항상 스트림이 제공한 인수로 표준 생성자를 호출하여 재구성됩니다. 따라서 컴팩트 생성자 내에서 실행되는 방어적 복사 논리는 변경 가능한 객체를 삽입하려는 악의적이거나 손상된 입력 스트림을 자동으로 정화합니다. 개발자들은 이 메커니즘을 간과하고 readObject 또는 readResolve 메서드를 레코드 내에서 불필요하게 구현하는 경우가 많습니다.
레코드의 컴팩트 생성자와 명시적으로 선언된 표준 생성자 사이에 어떤 바이트코드 차이가 있는가?
컴팩트 생성자는 invokespecial( Object의 생성자를 호출) 다음에 생성자 논리가 오고, 각 구성 요소에 대한 컴파일러 생성 putfield 명령어가 차례로 오는 바이트코드로 컴파일됩니다. 반면에 명시적 표준 생성자는 개발자가 작성한 putfield 작업을 포함합니다. 이 차이로 인해 컴팩트 생성자는 동일한 메서드 내에서 필드 초기화 후에 유효성을 검사하거나 논리를 수행할 수 없으며, 기본적으로 초기화 순서를 제약하고 모든 방어적 변환이 암시적 할당이 실행되기 전에 매개변수 변수에서 발생해야 합니다.