질문의 배경
Java 8 업데이트 20 이전, 중복 String 인스턴스로부터 힙 소비를 줄이려는 개발자들은 전적으로 **String.intern()**에 의존해야 했습니다. 이 메서드는 문자열을 영구 세대(후에 메타스페이스)에 배치하여 명시적 API 호출을 요구하고 인턴 풀에서 메모리 압박을 유발할 수 있었습니다. JEP 192와 함께, G1 가비지 수집기는 자동 String Deduplication을 도입하였으며, 이는 엔터프라이즈 애플리케이션에서 중복 문자 배열의 문제를 목표로 하는 투명한 최적화입니다.
문제
XML, JSON 또는 데이터베이스 결과 집합을 구문 분석하는 데이터 집약적인 Java 애플리케이션에서 String 객체는 종종 라이브 힙의 25-50%를 차지합니다. 이러한 문자열의 상당 부분은 문자별로 동일하지만 서로 다른 char[] (또는 Java 9 이후의 Compact Strings의 경우 byte[]) 백업 배열에 존재합니다. 개입 없이 이러한 중복 배열은 메모리를 낭비하고 GC 빈도를 증가시킵니다. 문제는 추가적인 정지-세계 중단 없이 코드 수정을 요구하지 않고 이 중복성을 제거하는 것이었습니다.
해결책
G1은 기존의 evacuation pause(스레드가 이미 중단된 상태) 동안 기회를 잡아 중복 제거를 수행합니다. -XX:+UseStringDeduplication이 활성화되면 수집기는 젊은 세대의 객체를 스캔합니다. 최소한 -XX:StringDeduplicationAgeThreshold 가비지 수집을 생존한 각 String에 대해 (기본값 3) G1은 백업 배열의 해시를 계산합니다. 그런 다음 중복 제거 테이블을 참조합니다. 동일한 배열이 존재하면 G1은 compare-and-swap (CAS) 작업을 사용하여 String의 value 필드를 기존 배열로 리디렉션하여 중복을 다음 주기에서 회수할 수 있도록 합니다. 이는 기존의 중단을 활용하여 마진 CPU 오버헤드만 추가합니다.
// 코드 변경이 필요 없음; JVM 플래그가 최적화를 활성화합니다: // -XX:+UseG1GC -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3 public class DeduplicationExample { public static void main(String[] args) { // 이 두 개의 문자열은 중복 제거 후 동일한 백업 배열을 공유합니다 String a = new String("FinancialInstrument".toCharArray()); String b = new String("FinancialInstrument".toCharArray()); // 충분한 GC 주기와 이주 중단 후, // a.value == b.value (내부 배열 참조 동등성) } }
FIX 프로토콜 메시지를 처리하는 고주파 거래 플랫폼은 200ms를 초과하는 심각한 G1 중단 시간을 경험했습니다. 프로파일링 결과 64GB 힙의 30%가 표준 태그(예: "55", "150", "EUR/USD")와 들어오는 바이트 스트림에서 구문 분석된 열거형 값들을 나타내는 String 객체로 소비되고 있음을 발견했습니다. 각 메시지 인스턴스는 **new String(byte[], Charset)**를 통해 새로운 String 인스턴스를 생성하여 매분 수백만 개의 중복 백업 배열을 초래했습니다.
여러 해결책이 평가되었습니다. **String.intern()**은 50개 이상의 메시지 유형에 걸쳐 침습적인 변경을 요구하며 메타스페이스를 고정 참조로 포화시킬 위험이 있었기 때문에 거부되었습니다. 맞춤형 WeakHashMap 기반 캐시가 프로토타입되었지만, 복잡한 동시성 오버헤드와 오래된 항목 정리 논리를 도입하여 paradoxically GC 압력을 증가시켰습니다.
팀은 최종적으로 기본 연령 기준이 3인 G1 String Deduplication을 활성화했습니다. 이 투명한 접근 방식은 코드 변경이 전혀 필요하지 않았으며 기존 이주 중단 동안 작동하여 새로운 정지-세계 단계 없이 수행되었습니다.
결과적으로 힙 사용량이 22% 감소하고 95번째 백분위수 중단 시간이 50ms 미만으로 떨어졌습니다. CPU 오버헤드는 피크 시장 시간 동안 약 1.5%로 측정되었으며, 이는 메모리 절약 및 대기 시간 개선을 고려할 때 허용 가능한 거래 비용이었습니다.
String 중복 제거가 Java 9의 Compact Strings와 어떻게 상호작용합니까? Compact Strings는 Latin-1 텍스트를 char[] 대신 byte[]로 저장합니다.
답변. String Deduplication은 Compact Strings가 활성화되었을 때 byte[] 배열에서 작동하도록 업데이트되었습니다(인 Java 9 이후의 기본값). 중복 제거 로직은 coder 필드(LATIN1 또는 UTF16)를 검사하고 해당하는 byte[] 또는 char[] 백업 배열을 해시합니다. 중복 제거 테이블은 해시와 배열 유형 모두에 의해 키가 지정된 항목을 저장하여 Latin-1 문자열은 다른 Latin-1 문자열에 대해 중복 제거되고, 전체 폭 UTF-16 문자열은 동료에 대해 중복 제거됩니다. 후보자들은 종종 이 기능이 Compact Strings와 함께 사용 중단되었다고 잘못 믿지만, 여전히 완전히 호환됩니다.
JVM이 String이 중복 제거 대상이 되기 전에 연령 기준(기본값 3 GC)을 부과하는 이유는 무엇입니까?
답변. 연령 기준은 시스템이 다음 젊은 수집에서 죽을 가능성이 높은 단명 문자열을 중복 제거하는 데 CPU 사이클을 낭비하지 않도록 방지합니다. String이 여러 G1 이주 주기를 생존해야 하며 (Eden에서 Survivor 영역으로, 결국 Tenured를 향해 승진) 이 경험적 기준은 "성숙한" 문자열—즉, 장기 생존 가능성이 높은 문자열만 처리되도록 보장합니다. 이는 객체의 예상 생존 기간에 따라 해시 계산 및 테이블 조회 비용을 분산시킵니다.
String 중복 제거가 String 인스턴스의 불변성이나 hashCode 안정성에 영향을 미칩니까?
답변. 아닙니다. 중복 제거 과정은 value 필드 참조 변형의 구현 세부 사항에 엄격히 해당합니다. 교체 배열이 동일한 바이트나 문자를 포함하므로 String의 논리적 상태와 hashCode는 변경되지 않습니다. hashCode는 String 객체 자체 내의 일시적 필드에 캐시되며, 내용이 동일하기 때문에 캐시된 값은 유효성을 유지합니다. 내용 동등성은 API 계약과 관련하여 백업 스토어의 참조 동등성이 중요하지 않음을 의미하기 때문에 equals 계약이 유지됩니다. 이 작업은 애플리케이션 관점에서 원자적이며, String의 불변성을 보장합니다.