역사: Java 8 이전에는 동시 누적이 AtomicLong에 의존했으며, 이 단일 메모리 위치는 스레드 경합 하에서 CPU 코어 간의 과도한 캐시 라인 무효화로 인해 확장성 병목 현상이 발생했습니다. 이에 대한 해결책으로 LongAdder가 java.util.concurrent.atomic 패키지의 일부로 소개되어 Striped64 알고리즘에서 영감을 받아서 여러 패딩된 셀에 걸쳐 쓰기 작업을 동적으로 분할하는 기술을 도입했습니다.
문제: 여러 스레드가 동시에 공유 AtomicLong에 대해 CAS 작업을 시도할 때마다 각 실패는 캐시 일관성 브로드캐스트를 유발하여 메모리 트래픽을 직렬화하고 코어 수에 따라 처리량이 기하급수적으로 악화됩니다. 이러한 현상을 캐시 라인 바운싱이라고 하며, 이는 다른 모든 병렬 작업에서도 선형 확장을 방해합니다.
해결책: LongAdder는 처음에 CAS를 사용하여 단일 기본 필드에서 업데이트를 시도합니다. 경합을 감지하면—특히 스레드가 확률적 탐색 시퀀스(일반적으로 Striped64에서 구현된 충돌 카운터와 스레드 로컬 해시를 사용) 후에 기본 잠금을 획득하지 못할 때—@Contended로 주석이 달린 Cell 객체의 배열을 느리게 할당합니다. 이후 각 스레드는 독립된 캐시 라인에서 경합 없는 추가 작업을 수행하며, sum() 메서드는 일관된 스냅샷이 필요할 때만 이러한 값을 느리게 집계합니다.
고주파 거래 플랫폼은 64코어 배포에서 주문 생산성을 검증하기 위해 전역 카운터가 필요했으며, 초기에는 AtomicLong을 사용하여 구현되었습니다. 시장 변동성이 급증하는 동안 시스템은 비선형 대기 시간 악화를 겪었으며, 99번째 백분위 응답 시간이 10배 증가하고, 프로파일링 결과 CPU 사이클의 40%가 카운터의 단일 메모리 주소에 대해 경쟁하는 캐시 일관성 프로토콜에 낭비되었습니다.
엔지니어링 팀은 세 가지 아키텍처 솔루션을 고려했습니다. 첫째, 각 스레드가 ConcurrentHashMap에 독립적인 AtomicLong을 유지하고 주기적으로 백그라운드 리포터가 집계하는 수동 스레드 로컬 카운터 맵을 평가했습니다. 이 방법은 경합을 제거했지만 스레드당 상당한 메모리 오버헤드와 스레드 풀 크기 조정 중 복잡한 라이프사이클 관리를 초래하여 장기 실행된 실행기에서 메모리 누수의 위험이 있었습니다. 둘째, 그들은 Thread.currentThread().getId() % 64에 의해 인덱스가 지정된 64개의 AtomicLong 인스턴스 배열을 사용한 사용자 정의 셔딩 전략을 프로토타입했습니다. 그러나 이 방법은 캐시 트래픽을 줄였지만 스레드 풀에서 ID를 재사용할 때 불균형 배포로 인해 트래픽 성장 중 배열 크기 조정을 수동으로 처리해야 하므로 유지보수의 부담이 가중되었습니다. 셋째, LongAdder로의 마이그레이션을 평가했으며, 이는 잘못된 공유를 방지하기 위한 자동 @Contended 패딩이 내장된 동적 스트라이핑을 제공했지만, 읽기 작업이 정확한 원자 값이 아닌 약한 일관성이 있는 근사치를 반환하는 거래가 있었습니다.
팀은 최종적으로 LongAdder를 선택했습니다. 비즈니스 요구 사항은 모니터링 대시보드를 위한 약간 오래된 읽기 값을 용납했으며, 쓰기 중심 검증 경로는 최대 처리량을 요구했습니다. 자동 셀 확장 휴리스틱은 트래픽이 저조한 기간 동안 객체가 경량 상태(단일 기본 필드)를 유지하도록 했으며, 높은 경합 시에는 패딩된 셀에 걸쳐 투명한 확장이 촉발되었습니다. 배포 후 대기 시간이 안정화되었으며, 처리량이 64코어까지 선형으로 확장되어 캐시 무효화 트래픽이 단일 핫스팟에서가 아닌 서로 다른 메모리 영역에 분산되도록 했습니다.
질문: 왜 **LongAdder.sum()**을 밀폐 루프에서 자주 폴링하면 스트라이핑의 성능 이점을 잠재적으로 상쇄하는가, 그리고 이 메서드는 어떤 일관성 보장을 제공하는가?
답변: sum() 메서드는 base 필드와 배열 내의 모든 활성 Cell을 탐색해야 총계를 계산하며, 이는 모든 참여 코어 간의 캐시 일관성 동기화를 유발하는 메모리 장벽이 필요합니다. 따라서 연속적인 읽기 중심 작업은 효과적으로 스트라이프된 쓰기를 직렬화하고 LongAdder가 회피하기 위해 설계된 경합을 다시 도입합니다. 또한, **sum()**은 약한 일관성만 제공하며, 동시 업데이트에 대한 원자성 보장 없이 호출 순간에만 정확한 값을 반환하므로 결과는 일부 스레드의 증가가 보이는 반면 다른 스레드는 그렇지 않은 일시적인 상태를 나타낼 수 있습니다.
질문: LongAdder의 내부 Cell 클래스 내에서 @Contended 주석이 잘못된 공유를 어떻게 방지하며, 이 패딩 동작을 관리하는 JVM 플래그는 무엇인가?
답변: @Contended는 HotSpot 컴파일러에게 각 Cell 내의 value 필드 주위에 128바이트(또는 -XX:ContendedPaddingWidth에 의해 지정된 값)의 패딩을 주입하도록 지시하여 인접한 배열 요소가 객체 레이아웃 최적화와 관계없이 별도의 캐시 라인에 위치하도록 보장합니다. 이 패딩이 없으면 연속적인 셀은 64바이트 캐시 라인을 공유하게 되어 한 셀에 대한 쓰기가 다른 코어의 이웃의 캐시 사본을 무효화하고 캐시 바운싱을 다시 도입하게 됩니다. 후보들은 이 주석이 JDK 내부 클래스에 예약되어 있다는 사실을 종종 간과하며, -XX:-RestrictContended가 명시적으로 비활성화되어 사용자 코드가 이를 활용할 수 있도록야 합니다.
질문: 어떤 특정 상황에서 LongAdder가 AtomicLong보다 더 나쁜 성능을 보이며, longValue() 구현이 이 위험에 어떤 영향을 미치는가?
답변: LongAdder는 경합 없는 단일 스레드 실행 중에도 Cell 배열과 해시 계산 로직에 대한 할당 오버헤드를 발생시킵니다. 이는 낮은 경합 시나리오나 단일 스레드에 의해서만 업데이트되는 카운터에 대해 AtomicLong이 우수하게 만듭니다. 또한, **longValue()**는 직접 **sum()**에 위임하므로 카운터의 값을 지속적으로 확인하는 어떤 코드 경로(예: 스핀 락 또는 백프레셔 알고리즘)는 모든 캐시 라인을 동기화하는 반복적인 글로벌 집계를 강제하여 스트라이프된 구조를 경합이 발생하는 단일 인스턴스로 변환하고 확장성을 파괴합니다.