Latency 메트릭 수집 — 구현 방식 비교와 HdrHistogram 내부 구조

private final AtomicLong[] bucketCounters = new AtomicLong[BUCKETS.length];

public void record(long latencyMs) {
    for (int i = 0; i < BUCKETS.length; i++) {
        if (latencyMs <= BUCKETS[i]) {
            bucketCounters[i].incrementAndGet();  // ← ⚠️ 이 한 줄
        }
    }
}

고빈도 환경에서 100k req/s가 들어오면 대부분이 p50 구간에 몰린다.
→ 특정 버킷 하나에 CAS가 집중된다.

1. Thread 1: 현재값 100 읽음, CAS(100 → 101) 성공
2. Thread 2: 현재값 100 읽음, CAS(100 → 101) 실패
              → 다시 읽음, CAS(101 → 102) 성공
3. Thread 3: 현재값 100 읽음, CAS(100 → 101) 실패
              → 다시 읽음, CAS(101 → 102) 실패
              → 다시 읽음, CAS(102 → 103) 성공

메모리:
[ bucket[0] ][ bucket[1] ][ bucket[2] ][ bucket[3] ][ bucket[4] ][ bucket[5] ][ bucket[6] ][ bucket[7] ]
|←─────────────────── 64 bytes (cache line 1개) ──────────────────────────────→|

상황:
  Thread A → bucket[0] 업데이트 (p10 구간)
  Thread B → bucket[3] 업데이트 (p50 구간) — 논리적으로는 별개

실제 CPU에서 벌어지는 일:
  Thread A가 bucket[0] 수정
    → CPU가 cache line을 "dirty"로 표시
    → Thread B의 같은 cache line을 무효화 (invalidate)
  Thread B가 bucket[3]을 읽으려 함
    → cache가 무효화됨 → 다시 메모리에서 로드 (cache miss)
  Thread B가 bucket[3] 수정
    → Thread A의 cache도 무효화
    → Thread A도 다시 메모리에서 로드

Recorder 내부:

  [Histogram A] ← 현재 쓰기 중 (active)
  [Histogram B] ← 사전 리셋 완료 (inactive)

getIntervalHistogram() 호출 시:
  1. Histogram B(inactive)를 미리 reset
  2. swap: B → active, A → inactive
  3. flipPhase() — A에 진행 중이던 write 완료 대기
  4. Histogram A(데이터 보존 상태)를 스냅샷으로 반환
  (A는 다음 호출 시 inactive로 reset됨)

// Recorder.java
public void recordValue(final long value) {
    // 1. WriterReaderPhaser에 진입 신고 (wait-free atomic increment)
    final long criticalValueAtEnter = recordingPhaser.writerCriticalSectionEnter();
    try {
        // 2. 현재 active histogram에 기록
        activeHistogram.recordValue(value);
    } finally {
        // 3. 진입 신고 해제
        recordingPhaser.writerCriticalSectionExit(criticalValueAtEnter);
    }
}

// WriterReaderPhaser.java
public long writerCriticalSectionEnter() {
    return evenPhaseUpdater.getAndIncrement(this); // 블로킹 없는 atomic add
}

일반 배열:
  [bucket0][bucket1][bucket2]... ← 붙어있음 → false sharing

padding 적용:
  [bucket0][///56bytes///][bucket1][///56bytes///]...
               ↑
          8 bytes 데이터 + 56 bytes 패딩 = 64 bytes
          → 각 버킷이 독립된 cache line 차지

private static final double[] BUCKETS = {1, 2, 5, 10, 20, 50, 75, 100, ...};
// record()가 O(k) 선형 탐색

값 → 상위 비트(exponent) + 하위 비트(sub-bucket)
  → 2차원 배열 인덱스로 직접 계산
  → 선형 탐색 없음, 비교 없음

예: latency = 150ms
  상위 비트: 7 (2^7 = 128 < 150 < 2^8 = 256)
  하위 비트: (150 - 128) / (128 / subBucketCount)
  → counts[7][sub-index]++ 직접 접근

// AbstractHistogram.java
int countsArrayIndex(final long value) {
    final int bucketIndex    = getBucketIndex(value);
    final int subBucketIndex = getSubBucketIndex(value, bucketIndex);
    return countsArrayIndex(bucketIndex, subBucketIndex);
}

private int getBucketIndex(final long value) {
    // value의 최상위 유효 비트 위치를 구함 → 어느 배율 구간인지 결정
    return leadingZeroCountBase - Long.numberOfLeadingZeros(value | subBucketMask);
}

private int getSubBucketIndex(final long value, final int bucketIndex) {
    // 해당 배율 구간 내에서 몇 번째 세부 슬롯인지 결정
    return (int)(value >>> (bucketIndex + unitMagnitude));
}