GC Deep Dive 시리즈 1편. G1 GC — Region 기반 메모리와 수집 과정 (현재 글) 2편. ZGC — Colored Pointer와 동시 수집

왜 G1 GC인가

JDK 9부터 기본 GC가 G1으로 바뀌었다. CMS가 deprecated 된 이후로 사실상 프로덕션에서 가장 많이 쓰이는 GC다. 그런데 막상 “Region이 뭔데?”라고 물으면 정확하게 설명하기 어려웠다. 이번에 제대로 정리해본다.

Region 기반 메모리 구조

기존 GC(Serial, Parallel, CMS)는 힙을 Young(Eden + Survivor)과 Old로 물리적으로 나눈다. 연속된 메모리 블록이라 Old 영역이 크면 Full GC 시간이 길어질 수밖에 없다.

G1은 접근이 다르다. 힙 전체를 동일 크기의 Region으로 잘게 쪼갠다. 기본적으로 1MB~32MB 사이인데, 힙 크기에 따라 JVM이 자동으로 결정한다. 보통 2048개 내외의 Region이 만들어진다.

각 Region은 다음 중 하나의 역할을 가진다:

핵심은 역할이 고정이 아니라는 점이다. 한 Region이 지금은 Eden이지만, GC 후에 Free가 되고, 나중에 Old가 될 수 있다. 이 유연성 때문에 G1이 pause time을 예측 가능하게 제어할 수 있다.

Humongous Region 주의점

Region 크기의 50% 이상인 객체는 Humongous로 분류된다. 문제는 Humongous 객체가 연속된 여러 Region을 차지할 수 있다는 것이다. 예를 들어 Region이 4MB인데 10MB 객체가 들어오면 3개의 연속 Region을 사용한다.

Humongous 객체는 Young GC에서 수집되지 않고, Mixed GC나 Full GC에서만 회수된다. 그래서 큰 byte 배열이나 컬렉션을 무분별하게 만들면 Humongous 할당이 빈번해지고, GC 효율이 떨어진다.

// Humongous 할당이 발생하는 전형적인 케이스
byte[] largeBuffer = new byte[4 * 1024 * 1024]; // 4MB — Region 크기에 따라 Humongous

// 이런 패턴은 피하자
List<byte[]> chunks = new ArrayList<>();
for (int i = 0; i < 100; i++) {
    chunks.add(new byte[2 * 1024 * 1024]); // 반복적인 대형 할당
}

Remember Set (RSet)과 Card Table

Region이 독립적으로 수집되려면 한 가지 문제를 풀어야 한다. 다른 Region에서 이 Region 안의 객체를 참조하고 있는지 어떻게 알 것인가?

Young GC를 한다고 하자. Eden Region의 객체가 살아있는지 확인하려면 Old Region에서 참조하는지도 봐야 한다. 그렇다고 Old 전체를 스캔하면 Young GC의 의미가 없다.

이 문제를 해결하는 게 RSet(Remembered Set)이다.

각 Region은 자신만의 RSet을 가진다. RSet에는 “나를 참조하는 다른 Region의 카드 정보”가 기록되어 있다. 여기서 카드(Card)는 512바이트 단위의 메모리 블록이다.

동작 방식을 좀 더 구체적으로 보면:

1. Old Region의 객체 A가 Eden Region의 객체 B를 참조한다
2. 이 참조가 생기는 시점에 Write Barrier가 작동한다
3. A가 위치한 카드를 dirty로 마킹한다
4. 별도의 Refinement Thread가 dirty 카드를 처리해서 B가 속한 Region의 RSet에 기록한다

Old Region [Card 0][Card 1][Card 2 - dirty]...[Card N]
                              |
                              ↓
Eden Region의 RSet: "Old Region의 Card 2에서 나를 참조함"

이렇게 하면 Young GC 때 Old 전체를 스캔할 필요 없이, RSet만 보면 외부 참조를 빠르게 파악할 수 있다. 단점은 RSet 자체가 힙의 일부를 차지한다는 것이다. 보통 힙의 5~10% 정도를 RSet이 사용한다.

G1 GC Collection 과정

G1의 수집은 크게 Young GC와 Mixed GC 두 가지로 나뉜다.

Young GC

Eden Region이 가득 차면 발생한다. 모든 Eden과 Survivor Region이 대상이다.

1. STW(Stop-The-World) 발생
2. GC Root에서 시작해서 살아있는 객체를 탐색
3. 살아있는 객체를 새로운 Survivor Region으로 복사 (age가 임계치를 넘으면 Old로 승격)
4. 기존 Eden/Survivor Region은 Free로 반환

Young GC는 비교적 빠르다. Eden Region 수를 조절해서 pause time 목표(-XX:MaxGCPauseMillis, 기본 200ms)에 맞추려 한다.

Mixed GC (Concurrent Marking + Mixed Collection)

Old 영역 사용량이 InitiatingHeapOccupancyPercent(기본 45%)를 넘으면 Concurrent Marking이 시작되고, 이후 Mixed GC가 수행된다.

Phase 1: Initial Mark (STW)

GC Root에서 직접 참조하는 객체만 마킹한다. Young GC에 편승(piggyback)해서 실행되기 때문에 별도의 STW가 추가되지 않는다.

Phase 2: Root Region Scan

Survivor Region을 스캔해서 Old Region으로의 참조를 찾는다. 애플리케이션 스레드와 동시에 실행된다. 다음 Young GC가 시작되기 전에 반드시 완료되어야 한다.

Phase 3: Concurrent Marking

힙 전체에서 살아있는 객체를 마킹한다. 애플리케이션과 동시에 실행된다. 이때 SATB(Snapshot-At-The-Beginning) 방식을 사용한다.

SATB는 마킹 시작 시점의 객체 그래프 스냅샷을 기준으로 “그 시점에 살아있던 객체는 모두 살아있다고 간주”하는 전략이다. Concurrent Marking 도중 애플리케이션이 참조를 변경하면, pre-write barrier가 변경 전 참조값을 SATB 큐에 기록한다.

// Concurrent Marking 중 참조 변경 시
obj.field = newRef;
// → pre-write barrier가 oldRef를 SATB 큐에 push
// → oldRef가 가리키던 객체는 이번 사이클에서 살아있다고 간주

이 방식의 장점은 마킹 도중 참조가 끊겨도 객체가 잘못 수집되는 일이 없다는 것이다. 대신 floating garbage(이미 죽었지만 이번에 못 거둔 객체)가 약간 발생할 수 있다. 다음 사이클에서 회수되니까 큰 문제는 아니다.

Phase 4: Remark (STW)

SATB 큐에 남아있는 참조들을 처리하고, 마킹을 최종 확정한다. 짧은 STW가 발생한다.

Phase 5: Cleanup / Evacuation

• 각 Region의 살아있는 객체 비율을 계산한다
• 가비지가 많은 Region을 우선적으로 수집 대상에 넣는다 (Garbage First의 이름 유래)
• 선택된 Region의 살아있는 객체를 다른 Region으로 복사(Evacuation)하고, 원래 Region은 Free로 반환한다

Mixed GC는 Young Region과 선택된 Old Region을 함께 수집한다. 한 번에 모든 Old Region을 처리하지 않고, pause time 목표에 맞춰 몇 개씩 나눠서 처리한다.

Young GC vs Mixed GC 정리

튜닝 포인트

실무에서 자주 건드리는 옵션 몇 가지:

# pause time 목표 (기본 200ms)
-XX:MaxGCPauseMillis=100

# Concurrent Marking 시작 임계치 (기본 45%)
-XX:InitiatingHeapOccupancyPercent=35

# Mixed GC에서 한 번에 수집할 Old Region 최대 수 (기본 8)
-XX:G1MixedGCCountTarget=8

# Region 크기 직접 지정 (보통 자동에 맡김)
-XX:G1HeapRegionSize=4m

MaxGCPauseMillis를 너무 낮게 잡으면 Young Region 수가 줄어들어 Young GC가 자주 발생하고, Old 승격이 빨라져서 오히려 Mixed GC나 Full GC가 늘어날 수 있다. 적정 값을 찾는 게 중요하다.

마무리

G1 GC의 핵심은 결국 “힙을 Region으로 쪼개서, 가비지가 많은 Region부터 선택적으로 수집한다”는 것이다. RSet으로 Region 간 참조를 추적하고, SATB로 Concurrent Marking의 정확성을 보장한다. 완벽하지는 않지만(RSet 오버헤드, Humongous 문제 등), 대부분의 서버 워크로드에서 합리적인 성능을 보여준다.

다음 글에서는 G1의 한계를 넘어서려는 ZGC의 Colored Pointer와 sub-millisecond pause에 대해 정리할 예정이다.

Reference

• Alibaba Cloud - JVM GC Deep Dive

JVM Internals 시리즈 1편. JVM 아키텍처와 런타임 데이터 영역 (현재 글) 2편. 클래스 로딩과 실행 엔진 3편. JVM 스레드와 스택 프레임 구조

왜 JVM 내부를 알아야 하는가

솔직히 말하면, 대부분의 Java 개발자가 JVM 내부를 몰라도 코드를 짤 수 있다. Spring Boot 띄우고 API 만들고 배포하는 데 Heap이 몇 개의 Generation으로 나뉘는지 알 필요는 없다.

그런데 운영 환경에서 문제가 터지면 얘기가 달라진다. OOM이 났는데 Heap dump를 보고도 뭐가 문제인지 모르겠다거나, GC 로그에 Full GC가 반복되는데 왜 그런지 감이 안 잡히거나. 이런 상황에서 JVM 구조를 아는 것과 모르는 것의 차이는 꽤 크다.

이 시리즈에서는 JVM 내부 구조를 3편에 걸쳐 정리한다. 첫 번째 글에서는 JVM의 전체 아키텍처와 Runtime Data Areas를 다룬다.

JVM 전체 아키텍처

JVM은 크게 세 파트로 나눌 수 있다:

1. Class Loader Subsystem — .class 파일을 읽어서 메모리에 올린다
2. Runtime Data Areas — 프로그램 실행에 필요한 데이터를 저장하는 메모리 공간
3. Execution Engine — 바이트코드를 실제로 실행한다

Class Loader와 Execution Engine은 다음 편에서 깊게 다룰 거고, 이 글에서는 Runtime Data Areas에 집중한다.

Runtime Data Areas

JVM이 프로그램을 실행하면서 사용하는 메모리 영역이다. 중요한 건 이 영역들이 스레드 공유 여부에 따라 나뉜다는 점이다.

이 구분이 중요한 이유는 동시성 문제와 직결되기 때문이다. 공유 영역에 있는 데이터는 여러 스레드가 동시에 접근할 수 있으니, synchronized나 volatile 같은 동기화 메커니즘이 필요해진다.

Heap

Java 개발자가 가장 많이 듣는 영역. new 키워드로 생성한 모든 객체 인스턴스와 배열이 여기에 저장된다.

// 이 객체는 Heap에 할당된다
User user = new User("jude", 28);

// 배열도 Heap
int[] scores = new int[100];

// String 리터럴은 String Pool(Heap 내부)에 저장
String name = "hello";

Heap은 GC(Garbage Collector)가 관리하는 영역이다. 더 이상 참조되지 않는 객체는 GC가 정리한다. JVM 옵션으로 크기를 조절할 수 있다:

# 초기 Heap 크기 256MB, 최대 1GB
java -Xms256m -Xmx1g -jar app.jar

Heap이 꽉 차면 OutOfMemoryError: Java heap space가 발생한다. 운영 환경에서 이 에러를 보면 보통 메모리 누수를 의심해야 한다.

Method Area (Metaspace)

클래스 수준의 정보가 저장되는 곳이다:

• 클래스의 런타임 상수 풀 (Runtime Constant Pool)
• 필드, 메서드 데이터
• 메서드와 생성자의 바이트코드
• static 변수

public class UserService {
    // static 변수 → Method Area에 저장
    private static final int MAX_RETRY = 3;

    // 메서드의 바이트코드 → Method Area에 저장
    public User findById(Long id) {
        // ...
    }
}

Java 8부터는 기존의 PermGen이 Metaspace로 대체됐다. 가장 큰 차이는 Metaspace가 Native Memory를 사용한다는 것이다. PermGen은 Heap 안에 있어서 크기가 고정이었는데, Metaspace는 OS 메모리를 직접 사용하므로 동적으로 확장된다.

# Metaspace 최대 크기 설정 (설정 안 하면 시스템 메모리까지 증가)
java -XX:MaxMetaspaceSize=256m -jar app.jar

동적 프록시를 많이 생성하는 프레임워크(Spring AOP 등)를 쓸 때 Metaspace가 계속 증가하는 경우가 있다. 이때 OutOfMemoryError: Metaspace가 나온다.

JVM Stack (Java Virtual Machine Stack)

스레드마다 하나씩 생성되는 영역이다. 메서드가 호출될 때마다 Stack Frame이 하나 push되고, 메서드가 리턴되면 pop된다.

public void methodA() {
    int x = 10;        // x는 methodA의 Stack Frame에 저장
    methodB();          // methodB의 Stack Frame이 push
}

public void methodB() {
    int y = 20;        // y는 methodB의 Stack Frame에 저장
    methodC();
}

// 호출 순서: methodA → methodB → methodC
// Stack: [methodA] → [methodA][methodB] → [methodA][methodB][methodC]
// 리턴하면 역순으로 pop

각 Stack Frame은 다음을 포함한다:

• Local Variables Array — 지역 변수와 파라미터
• Operand Stack — 바이트코드 연산에 사용되는 스택
• Frame Data — Constant Pool 참조, 예외 테이블 등

Stack의 깊이가 허용 범위를 초과하면 StackOverflowError가 발생한다. 재귀 호출이 끝나지 않을 때 흔히 볼 수 있다.

# 스레드당 Stack 크기 설정 (기본값은 보통 512KB ~ 1MB)
java -Xss1m -jar app.jar

PC Register (Program Counter Register)

각 스레드가 현재 실행 중인 JVM 명령어의 주소를 저장한다. 바이트코드 인터프리터가 다음에 실행할 명령어를 알기 위해 이 레지스터를 참조한다.

스레드가 Java 메서드를 실행 중이면 현재 바이트코드 명령어의 주소가 저장되고, Native 메서드를 실행 중이면 undefined 상태가 된다.

크기가 매우 작아서 OOM이 발생할 일은 없다. JVM 스펙상 이 영역에 대한 OutOfMemoryError는 정의되어 있지 않다.

Native Method Stack

JNI(Java Native Interface)를 통해 호출되는 네이티브 메서드(C/C++)를 위한 스택이다. Java 코드가 아닌 네이티브 코드 실행을 위한 영역이다.

// System.currentTimeMillis()는 내부적으로 네이티브 메서드를 호출
public static native long currentTimeMillis();

// Thread.sleep()도 네이티브 메서드
public static native void sleep(long millis) throws InterruptedException;

HotSpot JVM에서는 JVM Stack과 Native Method Stack을 구분하지 않고 하나로 합쳐서 관리한다. 하지만 JVM 스펙상으로는 별개의 영역이다.

정리: 메모리 영역과 에러 매핑

실무에서 만나는 에러와 메모리 영역의 관계를 정리하면:

JVM 튜닝이라는 게 결국 이 메모리 영역들의 크기와 GC 전략을 조절하는 작업이다. 어떤 영역에서 문제가 발생하는지 알아야 올바른 옵션을 적용할 수 있다.

다음 편에서는 .class 파일이 이 메모리 영역들에 어떻게 로딩되고, Execution Engine이 바이트코드를 어떻게 실행하는지 정리한다.

참고

• JVM Internals — James D Bloom
• The Java Virtual Machine Specification (Java SE 17)

모임 조회 API 시리즈 1단계. 튜닝 없이 v1 쿼리 분석 — 389초 (현재 글) 2단계. 쿼리 분리 + 복합 인덱스 — 389초 → 5초 3단계. ROW_NUMBER 제거 — 5초 → 317ms 4단계. Redis 캐시 + Redisson 분산 락 — p50 11ms

요구사항

모임 메인 페이지는 카테고리별 인기 모임 9개를 한 번에 보여줘야 한다. 카테고리가 20개라면 총 180개의 모임을 한 번의 API 호출로 반환해야 한다.

v1 쿼리: 단일 SQL로 모든 것을 해결

v1은 이 요구사항을 하나의 SQL로 해결했다.

SELECT id, title, content, registerDate, category, createdBy, url, count
FROM (
  SELECT g.id, g.title, g.content, g.register_date AS registerDate,
         ca.name AS category, cr.username AS createdBy, im.url AS url,
         ec.count AS count,
         ROW_NUMBER() OVER (PARTITION BY ca.name ORDER BY g.count DESC) AS rownum
  FROM gathering g
  LEFT JOIN category ca ON g.category_id = ca.id
  LEFT JOIN user cr ON g.user_id = cr.id
  LEFT JOIN image im ON g.image_id = im.id
  LEFT JOIN (
    SELECT COUNT(*) AS count, gathering_id
    FROM enrollment WHERE accepted = true
    GROUP BY gathering_id
  ) ec ON ec.gathering_id = g.id
) AS subquery
WHERE rownum BETWEEN 1 AND 9

JdbcGatheringRepository

public List<MainGatheringsProjection> gatherings() {
    String sql = "select id, title, content, registerDate, category, createdBy, url, count from ( " +
            "  select g.id as id, g.title as title, g.content as content, " +
            "         g.register_date as registerDate, ca.name as category, " +
            "         cr.username as createdBy, im.url as url, ec.count as count, " +
            "         row_number() over (partition by ca.name order by g.count desc) as rownum " +
            "  from gathering g " +
            "  left join category ca on g.category_id = ca.id " +
            "  left join user cr on g.user_id = cr.id " +
            "  left join image im on g.image_id = im.id " +
            "  left join (select count(*) as count, gathering_id " +
            "             from enrollment where accepted = true " +
            "             group by gathering_id) ec " +
            "  on ec.gathering_id = g.id" +
            ") as subquery " +
            "where rownum between 1 and 9";
    return jdbcTemplate.query(con -> con.prepareStatement(sql), mainGatheringsRowMapper());
}

GatheringService

public ApiResponse gatherings() {
    List<MainGatheringsProjection> mainGatheringElements = jdbcGatheringRepository.gatherings();
    Map<String, CategoryTotalGatherings> map = categorizeByCategory(mainGatheringElements);
    return toMainGatheringResponse(map);
}

한 번의 쿼리, 한 번의 서비스 호출. 코드만 보면 깔끔해 보인다.

문제 분석

하지만 이 쿼리에는 세 가지 구조적 문제가 숨어 있다.

1. gathering 99만 행 풀 스캔

ROW_NUMBER()는 전체 행에 번호를 매긴 뒤 WHERE rownum BETWEEN 1 AND 9로 필터링한다. 카테고리별로 9개만 필요하지만, 99만 행을 전부 읽고 정렬해야 번호를 매길 수 있다.

2. enrollment 전체 GROUP BY

SELECT COUNT(*) AS count, gathering_id
FROM enrollment WHERE accepted = true
GROUP BY gathering_id

이 서브쿼리는 accepted = true인 모든 enrollment 행을 집계한다. 최종적으로 필요한 건 선별된 180개 모임의 enrollment count뿐인데, 전체를 GROUP BY하고 있다.

3. 4개 테이블이 99만 행에 JOIN

category, user, image, enrollment — 이 4개 테이블 JOIN이 ROW_NUMBER() 필터링 이전에 발생한다. 99만 행 전부에 조인이 걸린다.

EXPLAIN ANALYZE 결과

• Table scan on g — rows=990,742, actual time=388,888~389,337ms
• Nested loop left join — 4개 테이블 중첩
• Group aggregate: count(0) — enrollment 전체 집계
• 전체 실행 시간: 약 389초 (6.5분)

Postman 결과

단일 요청 응답 시간: 7분 38초. API 하나가 DB 커넥션을 6분 이상 점유한다.

Reflection

“한 번의 쿼리로 끝낸다”는 것은 코드의 단순함이지, 성능의 단순함이 아니다. ROW_NUMBER()는 “카테고리별 Top N”을 우아하게 표현하지만, 그 대가로 99만 행 풀 스캔 + 정렬 + 4개 테이블 JOIN이라는 비용을 숨기고 있다.

EXPLAIN ANALYZE를 실행하기 전까지는 이 쿼리가 왜 느린지 체감하기 어렵다. 실행 계획을 확인하는 습관이 모든 최적화의 출발점이다.

하나의 거대한 SQL을 역할별로 분리하면 어떻게 되는가? 2단계: 쿼리 분리 + 복합 인덱스 — 389초 → 5초 →

모임 조회 API 시리즈 1단계. 튜닝 없이 v1 쿼리 분석 — 389초 2단계. 쿼리 분리 + 복합 인덱스 — 389초 → 5초 (현재 글) 3단계. ROW_NUMBER 제거 — 5초 → 317ms 4단계. Redis 캐시 + Redisson 분산 락 — p50 11ms

Problem

1단계에서 확인한 v1 쿼리의 핵심 병목:

1. enrollment 전체 GROUP BY가 메인 쿼리에 포함
2. category/user/image JOIN이 99만 행 전부에 발생
3. ROW_NUMBER()가 풀 스캔을 강제

이 중 1번과 2번은 쿼리 분리로 해결할 수 있다. 3번은 (category_id, count) 복합 인덱스를 추가하지만, ROW_NUMBER()가 남아있는 한 완전한 해결은 불가능하다.

Action

1. enrollment 서브쿼리 분리

v1은 enrollment 전체를 GROUP BY하는 서브쿼리가 메인 쿼리에 포함되어 있었다. 이를 별도 배치 쿼리로 분리하여, ROW_NUMBER()로 선별된 ID에만 집계한다.

Map<Long, Integer> enrollmentCounts =
    jdbcGatheringRepository.gatheringEnrollmentCounts(gatheringIds);

SELECT gathering_id, COUNT(*) AS count
FROM enrollment
WHERE accepted = true AND gathering_id IN (?, ?, ...)
GROUP BY gathering_id

99만 건 전체가 아니라, 최대 카테고리 수 × 9건에만 집계가 발생한다.

2. category JOIN 제거 → category_id로 변경

v1은 PARTITION BY ca.name으로 카테고리명 기준 파티션을 나눴다. 이를 category_id(FK)로 변경하면 category JOIN 없이 gathering 테이블 단독으로 파티션을 나눌 수 있다.

-- v2: category JOIN 제거, gathering 단독 서브쿼리
SELECT g.id, g.title, g.content, g.register_date AS registerDate,
       g.category_id AS categoryId, cr.username AS createdBy, im.url AS url
FROM (
  SELECT g.*, ROW_NUMBER() OVER (PARTITION BY g.category_id ORDER BY g.count DESC) AS rownum
  FROM gathering g
) g
LEFT JOIN user cr ON g.user_id = cr.id
LEFT JOIN image im ON g.image_id = im.id
WHERE g.rownum BETWEEN 1 AND 9

내부 서브쿼리가 SELECT g.*만 처리하므로, user/image JOIN이 ROW_NUMBER() 필터링 이후에 발생한다. 180건에만 JOIN이 걸린다.

3. 카테고리명은 Java Map으로 해결

Map<Long, String> categoryNameMap = categoryRepository.findAll().stream()
    .collect(Collectors.toMap(Category::getId, Category::getName));

카테고리는 수십 개 이하의 소규모 테이블이므로, findAll()로 한 번 로드하여 메모리에서 매핑하는 것이 SQL JOIN보다 효율적이다.

4. 복합 인덱스 추가

CREATE INDEX idx_gathering_category_count ON gathering (category_id, count DESC);

(category_id, count) 복합 인덱스를 추가했지만, ROW_NUMBER()가 전체 행에 번호를 매기는 특성상 옵티마이저가 이 인덱스를 선택하지 않는다.

JdbcGatheringRepository

public List<MainGatheringsProjectionV2> gatheringsV2() {
    String sql = "select g.id, g.title, g.content, g.register_date as registerDate, " +
            "g.category_id as categoryId, cr.username as createdBy, im.url as url " +
            "from ( " +
            "  select g.*, row_number() over (partition by g.category_id order by g.count desc) as rownum " +
            "  from gathering g " +
            ") g " +
            "left join user cr on g.user_id = cr.id " +
            "left join image im on g.image_id = im.id " +
            "where g.rownum between 1 and 9";
    return jdbcTemplate.query(con -> con.prepareStatement(sql), mainGatheringsV2RowMapper());
}

GatheringService

public ApiResponse gatheringsV2() {
    List<MainGatheringsProjectionV2> projections = jdbcGatheringRepository.gatheringsV2();

    List<Long> gatheringIds = projections.stream()
            .map(MainGatheringsProjectionV2::getId).toList();
    Map<Long, Integer> enrollmentCounts =
            jdbcGatheringRepository.gatheringEnrollmentCounts(gatheringIds);

    Map<Long, String> categoryNameMap = categoryRepository.findAll().stream()
            .collect(Collectors.toMap(Category::getId, Category::getName));

    List<MainGatheringsProjection> mainGatheringElements = projections.stream()
            .map(p -> MainGatheringsProjection.builder()
                    .id(p.getId())
                    .title(p.getTitle())
                    .content(p.getContent())
                    .registerDate(p.getRegisterDate())
                    .category(categoryNameMap.getOrDefault(p.getCategoryId(), "unknown"))
                    .createdBy(p.getCreatedBy())
                    .url(p.getUrl())
                    .count(enrollmentCounts.getOrDefault(p.getId(), 0))
                    .build())
            .toList();

    Map<String, CategoryTotalGatherings> map = categorizeByCategory(mainGatheringElements);
    return toMainGatheringResponse(map);
}

Result

EXPLAIN ANALYZE

• Table scan on g — rows=990,742 (여전히 풀 스캔)
• Materialize + Window aggregate: row_number() — actual time=4568~4568ms
• Nested loop left join — rows=180에만 user/image JOIN 발생
• 전체: 약 5초

쿼리 분리만으로 389초 → 5초, 약 78배 개선됐다. 하지만 ROW_NUMBER()가 gathering 99만 행 풀 스캔을 강제하는 구조는 변하지 않았다.

Locust 100명 부하테스트

• 0.5 RPS, 61% 요청 실패
• p50 84,000ms / p95 84,000ms

Grafana — HikariCP

• Active connections: 10 (풀 전체 고갈)
• Pending threads: 91 — 커넥션을 얻지 못해 대기하는 스레드
• 쿼리 하나가 5초 동안 커넥션을 점유하면서, 동시 100명의 요청이 줄줄이 밀리는 구조

RDS — DBLoadCPU

• DBLoadCPU: 2.47 — 풀 스캔으로 인한 CPU 부하 급등

Reflection

하나의 SQL에 모든 것을 담으면 “한 번에 끝난다”는 편안함이 있다. 하지만 그 안에서 enrollment 전체 집계, category JOIN, user/image JOIN이 99만 행에 중첩되면, 각각은 작은 비용이라도 곱셈으로 폭발한다.

쿼리 분리의 핵심은 “이 JOIN이 정말 99만 행 전부에 필요한가?”를 묻는 것이다. enrollment count는 최종 선별된 ID에만 필요하고, 카테고리명은 수십 개짜리 테이블이다. 분리하면 각각의 비용이 독립적으로 최소화된다.

그러나 ROW_NUMBER()가 풀 스캔을 강제하는 한, 인덱스를 추가해도 효과가 없다. 복합 인덱스 (category_id, count)는 존재하지만 옵티마이저가 선택하지 않는다. 이 구조적 한계를 넘으려면 ROW_NUMBER() 자체를 제거해야 한다.

ROW_NUMBER()를 제거하면 비로소 복합 인덱스가 동작한다. 3단계: ROW_NUMBER 제거 — 5초 → 317ms →

모임 조회 API 시리즈 1단계. 튜닝 없이 v1 쿼리 분석 — 389초 2단계. 쿼리 분리 + 복합 인덱스 — 389초 → 5초 3단계. ROW_NUMBER 제거 — 5초 → 317ms (현재 글) 4단계. Redis 캐시 + Redisson 분산 락 — p50 11ms

Problem

2단계에서 쿼리 분리로 389초 → 5초까지 개선했지만, ROW_NUMBER()가 풀 스캔을 강제하는 구조적 한계가 남아 있었다.

v2 쿼리의 내부 서브쿼리:

SELECT g.*, ROW_NUMBER() OVER (PARTITION BY g.category_id ORDER BY g.count DESC) AS rownum
FROM gathering g

(category_id, count) 복합 인덱스가 존재하지만, ROW_NUMBER()는 전체 행에 번호를 매긴 뒤 WHERE rownum BETWEEN 1 AND 9로 필터링하므로, MySQL 옵티마이저는 인덱스 대신 풀 스캔을 선택할 수밖에 없다.

인덱스를 추가하는 것만으로는 해결되지 않는다. ROW_NUMBER() 자체를 제거해야 인덱스가 동작한다.

Action

핵심 전략: ROW_NUMBER() 제거 → 카테고리별 단순 쿼리 전환

“카테고리별 인기 9개”를 구하는 데 ROW_NUMBER()가 반드시 필요한가?

카테고리별로 개별 쿼리를 날리면, 각 쿼리는 WHERE + ORDER BY + LIMIT만으로 충분하다. 이 구조는 복합 인덱스를 100% 활용할 수 있다.

v3 쿼리: 카테고리별 LIMIT 9

SELECT g.id, g.title, g.content, g.register_date AS registerDate,
       g.category_id AS categoryId, cr.username AS createdBy, im.url AS url
FROM gathering g
LEFT JOIN user cr ON g.user_id = cr.id
LEFT JOIN image im ON g.image_id = im.id
WHERE g.category_id = ?
ORDER BY g.count DESC
LIMIT 9

WHERE category_id = ? ORDER BY count DESC LIMIT 9 — 이 조합은 (category_id, count) 복합 인덱스를 타면 인덱스 레인지 스캔으로 9건만 읽고 즉시 반환한다.

JdbcGatheringRepository

public List<MainGatheringsProjectionV2> gatheringsV3(Long categoryId) {
    String sql = "select g.id, g.title, g.content, g.register_date as registerDate, " +
            "g.category_id as categoryId, cr.username as createdBy, im.url as url " +
            "from gathering g " +
            "left join user cr on g.user_id = cr.id " +
            "left join image im on g.image_id = im.id " +
            "where g.category_id = ? " +
            "order by g.count desc " +
            "limit 9";
    return jdbcTemplate.query(con -> {
        PreparedStatement pstmt = con.prepareStatement(sql);
        pstmt.setLong(1, categoryId);
        return pstmt;
    }, mainGatheringsV2RowMapper());
}

GatheringService: 카테고리별 반복 호출

public ApiResponse gatheringsV3() {
    Map<Long, String> categoryNameMap = categoryRepository.findAll().stream()
            .collect(Collectors.toMap(Category::getId, Category::getName));

    List<MainGatheringsProjectionV2> projections = categoryNameMap.keySet().stream()
            .flatMap(categoryId ->
                jdbcGatheringRepository.gatheringsV3(categoryId).stream())
            .toList();

    List<Long> gatheringIds = projections.stream()
            .map(MainGatheringsProjectionV2::getId).toList();
    Map<Long, Integer> enrollmentCounts =
            jdbcGatheringRepository.gatheringEnrollmentCounts(gatheringIds);

    List<MainGatheringsProjection> mainGatheringElements = projections.stream()
            .map(p -> MainGatheringsProjection.builder()
                    .id(p.getId())
                    .title(p.getTitle())
                    .content(p.getContent())
                    .registerDate(p.getRegisterDate())
                    .category(categoryNameMap.getOrDefault(p.getCategoryId(), "unknown"))
                    .createdBy(p.getCreatedBy())
                    .url(p.getUrl())
                    .count(enrollmentCounts.getOrDefault(p.getId(), 0))
                    .build())
            .toList();

    Map<String, CategoryTotalGatherings> map = categorizeByCategory(mainGatheringElements);
    return toMainGatheringResponse(map);
}

카테고리가 20개면 쿼리 20번 + enrollment 배치 1번 = 총 21번. ROW_NUMBER()의 99만 행 풀 스캔 대비 각 쿼리가 인덱스로 9건만 읽으므로, N번의 라운드트립 비용을 감안해도 압도적으로 빠르다.

Result

EXPLAIN ANALYZE

• Index lookup on g using idx_gathering_category_count — rows=9, actual time 0.02~0.05ms
• Limit: 9 row(s) — 인덱스에서 9건 읽고 즉시 반환
• 개별 쿼리: 0.17ms

5초 → 317ms (15배 개선). 개별 쿼리는 0.17ms지만, 카테고리 수만큼 반복 + enrollment 배치 + 네트워크 오버헤드를 합산하면 실제 API 응답은 317ms다.

Locust 100명 부하테스트

• 28 RPS, 0% 실패
• p50 1,600ms / p95 1,900ms

이전 61% 실패에서 0% 실패로 전환됐다.

Grafana — HikariCP

• Active connections: 10
• Pending threads: 33 — v2의 91에서 크게 감소
• 개별 쿼리가 빨라졌지만, 카테고리 수만큼 커넥션을 반복 사용하면서 여전히 대기 발생

RDS — DBLoadCPU

• DBLoadCPU: 0.12 — v2의 2.47에서 95% 감소
• 인덱스 레인지 스캔으로 CPU 부하가 극적으로 줄었다

Reflection

ROW_NUMBER()는 “한 번의 쿼리로 카테고리별 Top N”을 구하는 우아한 방법이다. 하지만 전체 행에 번호를 매기는 특성상 인덱스를 무력화한다. 99만 행에서 9개만 필요한데, 99만 행을 전부 읽고 정렬한 뒤 9개를 고르는 것이다.

ROW_NUMBER()를 제거하고 카테고리별 단순 쿼리로 전환하면, 비로소 복합 인덱스가 동작한다. 쿼리 횟수는 늘어나지만, 각 쿼리가 인덱스로 9건만 읽으므로 총 비용은 비교할 수 없을 만큼 작다.

다만 p50 1,600ms / p95 1,900ms로 응답 지연이 남아 있다. 카테고리 수만큼 쿼리가 발생하는 구조적 한계 — 카테고리가 늘어날수록 쿼리 수가 선형 증가한다. 이 한계를 넘으려면 캐시 레이어가 필요하다.

쿼리 튜닝의 한계를 캐시로 보완한다. Redis + Redisson 분산 락 + DB fallback. 4단계: Redis 캐시 + Redisson 분산 락 — p50 11ms →

모임 조회 API 시리즈 1단계. 튜닝 없이 v1 쿼리 분석 — 389초 2단계. 쿼리 분리 + 복합 인덱스 — 389초 → 5초 3단계. ROW_NUMBER 제거 — 5초 → 317ms 4단계. Redis 캐시 + Redisson 분산 락 — p50 11ms (현재 글)

Problem

3단계에서 복합 인덱스로 개별 쿼리는 0.17ms까지 줄였지만, 카테고리 수만큼 쿼리가 발생하는 구조적 한계가 남아 있었다.

Locust 100명 부하테스트:

• 28 RPS, 0% 실패
• p50 1,600ms / p95 1,900ms

카테고리가 20개면 쿼리 20번 + enrollment 배치 1번 = 21번의 DB 왕복이 매 요청마다 발생한다. 개별 쿼리가 아무리 빨라도, 동시 100명이 각각 21번씩 DB를 때리면 커넥션 풀과 네트워크 오버헤드가 병목이 된다.

모임 메인 페이지는 모든 사용자에게 동일한 결과를 보여준다. 사용자별 개인화가 없으므로, 캐싱에 이상적인 엔드포인트다.

Action

캐시 설계: Redis + DB fallback + Redisson 분산 락

단순히 Redis에 캐싱하면 끝나는 게 아니다. 세 가지 문제를 동시에 해결해야 한다:

1. 캐시 스탬피드 — TTL 만료 시 동시 100명이 한꺼번에 DB를 조회
2. Redis 장애 — Redis가 내려가면 캐시 자체가 불가능
3. 데이터 정합성 — 캐시가 너무 오래되면 사용자 경험 저하

1. Soft TTL + Hard TTL: stale-while-revalidate

private static final Duration CACHE_TTL = Duration.ofMinutes(60);   // Hard TTL
private static final Duration SOFT_TTL = Duration.ofMinutes(55);    // Soft TTL

• Hard TTL 60분: Redis 키 자체의 만료 시간
• Soft TTL 55분: 남은 TTL이 5분 이하일 때 한 스레드만 선점하여 갱신

현재 요청은 기존 캐시(약간 stale)를 그대로 반환하고, 백그라운드에서 갱신이 완료되면 다음 요청부터 새 데이터를 받는다.

private void triggerRefreshIfNeeded(Supplier<List<MainGatheringsProjection>> dbLoader) {
    try {
        Long remainTtl = redisTemplate.getExpire(CACHE_KEY, TimeUnit.MINUTES);
        if (remainTtl == null || remainTtl > (CACHE_TTL.toMinutes() - SOFT_TTL.toMinutes())) {
            return;  // 아직 여유 있음
        }

        // 남은 TTL 5분 이하 → 하나의 스레드만 갱신
        RLock lock = redissonClient.getLock(LOCK_KEY);
        boolean acquired = lock.tryLock(0, LOCK_LEASE_TIME, TimeUnit.SECONDS);
        if (acquired) {
            try {
                List<MainGatheringsProjection> result = dbLoader.get();
                String json = serialize(result);
                redisTemplate.opsForValue().set(CACHE_KEY, json, CACHE_TTL);
                saveToDbCache(json);
            } finally {
                lock.unlock();
            }
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } catch (Exception e) {
        log.warn("Cache refresh failed", e);
    }
}

tryLock(0, ...) — wait 시간 0초. 락을 잡지 못하면 즉시 포기한다. 이미 다른 스레드가 갱신 중이므로, 나머지 스레드는 기존 캐시를 반환하면 된다.

2. Redisson 분산 락: 캐시 미스 시 보호

캐시 미스(Redis에 키가 없는 상태)일 때, 동시 100명이 한꺼번에 DB를 조회하는 캐시 스탬피드를 방지한다.

private List<MainGatheringsProjection> loadWithLock(Supplier<List<MainGatheringsProjection>> dbLoader) {
    RLock lock = redissonClient.getLock(LOCK_KEY);
    try {
        boolean acquired = lock.tryLock(3, LOCK_LEASE_TIME, TimeUnit.SECONDS);
        if (acquired) {
            try {
                // Double-check: 다른 스레드가 이미 채웠을 수 있음
                String cached = redisTemplate.opsForValue().get(CACHE_KEY);
                if (cached != null) return deserialize(cached);

                List<MainGatheringsProjection> result = dbLoader.get();
                String json = serialize(result);
                redisTemplate.opsForValue().set(CACHE_KEY, json, CACHE_TTL);
                saveToDbCache(json);
                return result;
            } finally {
                lock.unlock();
            }
        } else {
            // 락 획득 실패 → 다른 스레드가 채운 캐시 확인
            String cached = redisTemplate.opsForValue().get(CACHE_KEY);
            if (cached != null) return deserialize(cached);
            return getFromDbCacheOrLoad(dbLoader);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        return getFromDbCacheOrLoad(dbLoader);
    } catch (Exception e) {
        log.warn("Redis failed during loadWithLock, fallback to DB cache", e);
        return getFromDbCacheOrLoad(dbLoader);
    }
}

• tryLock(3, 30, SECONDS) — 최대 3초 대기, 30초 lease
• Double-check locking: 락 획득 후 Redis를 다시 확인. 대기 중에 다른 스레드가 캐시를 채웠을 수 있다.

3. DB 캐시 fallback: Redis 장애 대비

Redis가 완전히 내려간 상황에서도 서비스가 동작해야 한다. gathering_cache 테이블에 동일한 데이터를 저장한다.

private void saveToDbCache(String json) {
    try {
        String sql = "INSERT INTO gathering_cache (cache_key, data, expired_at, created_at) " +
                "VALUES (?, ?, ?, ?) " +
                "ON DUPLICATE KEY UPDATE data = VALUES(data), " +
                "expired_at = VALUES(expired_at), created_at = VALUES(created_at)";
        jdbcTemplate.update(sql, CACHE_KEY, json,
                LocalDateTime.now().plus(CACHE_TTL), LocalDateTime.now());
    } catch (Exception e) {
        log.warn("DB cache save failed", e);
    }
}

private List<MainGatheringsProjection> getFromDbCacheOrLoad(
        Supplier<List<MainGatheringsProjection>> dbLoader) {
    try {
        String sql = "SELECT data FROM gathering_cache " +
                "WHERE cache_key = ? AND expired_at > NOW() LIMIT 1";
        List<String> results = jdbcTemplate.queryForList(sql, String.class, CACHE_KEY);
        if (!results.isEmpty()) {
            return deserialize(results.get(0));
        }
    } catch (Exception e) {
        log.warn("DB cache read failed", e);
    }
    return dbLoader.get();  // 최종 fallback: 직접 DB 조회
}

ON DUPLICATE KEY UPDATE로 캐시 키 기준 upsert. Redis 장애 시 이 테이블에서 만료되지 않은 데이터를 반환한다. DB 캐시마저 없으면 직접 DB 조회로 최종 fallback한다.

4. 메인 진입점: getOrLoad

public List<MainGatheringsProjection> getOrLoad(Supplier<List<MainGatheringsProjection>> dbLoader) {
    // 1. Redis 시도
    try {
        String cached = redisTemplate.opsForValue().get(CACHE_KEY);
        if (cached != null) {
            cacheHitCounter.increment();
            triggerRefreshIfNeeded(dbLoader);
            return deserialize(cached);
        }
    } catch (Exception e) {
        cacheMissCounter.increment();
        log.warn("Redis read failed, fallback to DB cache", e);
        return getFromDbCacheOrLoad(dbLoader);
    }

    // 2. 캐시 미스 - 락 잡고 로드
    cacheMissCounter.increment();
    return loadWithLock(dbLoader);
}

5. Micrometer 캐시 히트율 모니터링

this.cacheHitCounter = Counter.builder("gathering_cache_hit")
        .description("Gathering cache hit count")
        .register(meterRegistry);
this.cacheMissCounter = Counter.builder("gathering_cache_miss")
        .description("Gathering cache miss count")
        .register(meterRegistry);

Prometheus/Grafana에서 캐시 히트율을 실시간으로 모니터링할 수 있다.

GatheringService: v4

public ApiResponse gatheringsV4() {
    List<MainGatheringsProjection> mainGatheringElements =
        gatheringCacheService.getOrLoad(this::loadGatheringsFromDb);
    Map<String, CategoryTotalGatherings> map = categorizeByCategory(mainGatheringElements);
    return toMainGatheringResponse(map);
}

loadGatheringsFromDb()는 v3의 로직과 동일하다. 캐시 hit 시에는 DB 쿼리가 0번 발생한다.

Result

Locust 100명 부하테스트

• 49.4 RPS, 0% 실패
• p50 11ms / p95 15ms

전체 시리즈 비교

Reflection

쿼리 튜닝만으로는 한계가 있다. 복합 인덱스로 개별 쿼리를 0.17ms까지 줄여도, 카테고리 수만큼 쿼리가 발생하는 구조적 문제는 남는다. 이 한계를 인식하고 캐시 레이어를 도입한 것이 핵심 판단이었다.

캐시를 도입할 때 가장 중요한 질문은 “Redis가 죽으면?”이다. Redisson 분산 락으로 스탬피드를 막고, DB 캐시 테이블로 Redis 장애에 대비하고, Micrometer로 히트율을 모니터링하는 3중 안전장치가 운영 환경에서의 신뢰성을 보장한다.

모임 조회 API 시리즈 완결 1단계. 튜닝 없이 v1 쿼리 분석 — 389초 2단계. 쿼리 분리 + 복합 인덱스 — 389초 → 5초 3단계. ROW_NUMBER 제거 — 5초 → 317ms 4단계. Redis 캐시 + Redisson 분산 락 — p50 11ms (현재 글)

JVM Internals 시리즈 1편. JVM 아키텍처와 런타임 데이터 영역 2편. 클래스 로딩과 실행 엔진 (현재 글) 3편. JVM 스레드와 스택 프레임 구조

클래스는 언제 메모리에 올라가는가

지난 편에서 Runtime Data Areas를 정리했는데, 그럼 .class 파일이 이 메모리 영역에 어떤 과정을 거쳐서 올라가는지가 이번 주제다.

Java에서 new UserService()를 호출하면, JVM은 먼저 UserService 클래스가 이미 로딩되어 있는지 확인한다. 로딩되어 있지 않으면 Class Loader가 작동한다.

Class Loading Process

클래스 로딩은 세 단계를 거친다: Loading → Linking → Initialization

1단계: Loading

.class 파일의 바이트코드를 읽어서 Method Area에 저장하는 단계다. 이때 해당 클래스를 나타내는 java.lang.Class 객체가 Heap에 생성된다.

// 이 코드를 실행하면 Loading 단계에서 만들어진 Class 객체를 얻는다
Class<?> clazz = UserService.class;
// 또는
Class<?> clazz = Class.forName("com.example.UserService");

Loading은 세 가지 종류의 Class Loader가 계층적으로 처리한다:

1. Bootstrap Class Loader — java.lang.*, java.util.* 같은 핵심 Java API 로딩. C/C++로 구현되어 있어서 Java 코드에서 참조하면 null이 나온다.
2. Extension (Platform) Class Loader — $JAVA_HOME/lib/ext 디렉토리의 클래스 로딩. Java 9부터는 Platform Class Loader로 이름이 바뀜.
3. Application (System) Class Loader — classpath에 있는 애플리케이션 클래스 로딩. 우리가 작성한 코드는 대부분 여기서 로딩된다.

public class ClassLoaderTest {
    public static void main(String[] args) {
        // Application ClassLoader
        System.out.println(ClassLoaderTest.class.getClassLoader());
        // sun.misc.Launcher$AppClassLoader@...

        // Bootstrap ClassLoader (null로 표시)
        System.out.println(String.class.getClassLoader());
        // null

        // 부모 관계 확인
        ClassLoader appLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(appLoader.getParent());
        // sun.misc.Launcher$ExtClassLoader@...
        System.out.println(appLoader.getParent().getParent());
        // null (Bootstrap)
    }
}

Parent Delegation Model (부모 위임 모델)

클래스 로딩 요청이 들어오면, 자기가 직접 로딩하지 않고 먼저 부모 Class Loader에게 위임한다. 부모가 못 찾으면 그때 자기가 로딩을 시도한다.

요청: "com.example.UserService 로딩해줘"
Application ClassLoader → "부모한테 먼저 물어볼게"
  → Extension ClassLoader → "나도 부모한테 물어볼게"
    → Bootstrap ClassLoader → "나한테 없음"
  → Extension ClassLoader → "나한테도 없음"
→ Application ClassLoader → "내가 로딩함" ✓

이 모델의 목적은 핵심 Java 클래스를 보호하는 것이다. 만약 누군가 java.lang.String 클래스를 직접 만들어서 classpath에 넣어도, Bootstrap Class Loader가 먼저 진짜 String을 로딩하기 때문에 위조된 클래스는 무시된다.

2단계: Linking

Linking은 다시 세 하위 단계로 나뉜다:

Verification (검증)

• 로딩된 바이트코드가 JVM 스펙에 맞는지 검사한다
• 매직 넘버(0xCAFEBABE)가 맞는지, 바이트코드 구조가 유효한지 등
• 잘못된 .class 파일이 JVM을 크래시시키는 걸 방지한다

# .class 파일의 매직 넘버 확인
xxd MyClass.class | head -1
# 00000000: cafe babe 0000 0034 ...

Preparation (준비)

• static 변수에 기본값을 할당한다 (실제 초기값이 아님!)
• int는 0, boolean은 false, 참조 타입은 null

public class Config {
    static int maxRetry = 5;  // Preparation 단계에서는 0으로 초기화
                               // 5가 할당되는 건 Initialization 단계
    static boolean enabled = true;  // 여기서는 false
}

Resolution (해석)

• 심볼릭 레퍼런스를 실제 메모리 주소(다이렉트 레퍼런스)로 변환한다
• Constant Pool의 심볼릭 참조가 실제 메모리 참조로 바뀌는 단계
• 이 단계는 필요할 때(lazy) 수행될 수도 있다

3단계: Initialization

실제 초기값 할당이 이루어지는 단계다. static 변수에 코드에서 지정한 값이 할당되고, static 블록이 실행된다.

public class DatabaseConfig {
    // Initialization 단계에서 "jdbc:mysql://localhost:3306/mydb"가 할당
    static String url = "jdbc:mysql://localhost:3306/mydb";

    static {
        // static 초기화 블록도 이 단계에서 실행
        System.out.println("DatabaseConfig initialized");
    }
}

Initialization은 JVM이 보장하는 thread-safe 작업이다. 여러 스레드가 동시에 같은 클래스의 초기화를 시도해도, 실제로 초기화는 한 번만 수행된다. 이게 Singleton 패턴에서 static inner class를 활용하는 이유이기도 하다.

// thread-safe한 Singleton (클래스 로딩의 Initialization 보장을 활용)
public class Singleton {
    private Singleton() {}

    private static class Holder {
        // Holder 클래스가 최초 참조될 때 한 번만 초기화
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;  // Holder 클래스 로딩 트리거
    }
}

Execution Engine

클래스가 메모리에 올라갔으면 이제 실행할 차례다. Execution Engine은 Method Area에 있는 바이트코드를 읽어서 실행한다.

Interpreter

바이트코드 명령어를 한 줄씩 해석하고 실행한다. 시작 속도가 빠르지만, 같은 메서드를 반복 호출해도 매번 해석하기 때문에 전체적인 성능은 떨어진다.

// 이 메서드가 10000번 호출되면, Interpreter는 매번 바이트코드를 해석한다
public int add(int a, int b) {
    return a + b;
}

JIT Compiler (Just-In-Time Compiler)

Interpreter의 성능 문제를 보완한다. 자주 실행되는 코드(Hot Code)를 감지해서 네이티브 코드로 컴파일한다. 한 번 컴파일되면 이후에는 네이티브 코드를 직접 실행하므로 훨씬 빠르다.

# JIT 컴파일 로그 확인
java -XX:+PrintCompilation -jar app.jar

# 출력 예시:
# 100   1       java.lang.String::hashCode (55 bytes)
# 110   2       java.lang.String::equals (81 bytes)

HotSpot JVM에는 두 가지 JIT 컴파일러가 있다:

• C1 (Client Compiler) — 빠르게 컴파일하지만 최적화 수준이 낮음. 시작 속도가 중요한 클라이언트 애플리케이션에 적합.
• C2 (Server Compiler) — 컴파일은 느리지만 고도로 최적화된 코드를 생성. 장시간 실행되는 서버 애플리케이션에 적합.

현대 JVM은 Tiered Compilation을 사용한다. 처음에는 Interpreter로 시작하고, 자주 호출되는 메서드는 C1으로 먼저 컴파일, 더 자주 호출되면 C2로 재컴파일한다.

# Tiered Compilation (Java 8부터 기본 활성화)
java -XX:+TieredCompilation -jar app.jar

# 컴파일 임계값 확인 (기본 10000)
java -XX:+PrintFlagsFinal -version | grep CompileThreshold

JIT가 수행하는 대표적인 최적화:

• Inlining — 메서드 호출을 메서드 본문으로 대체
• Dead Code Elimination — 실행되지 않는 코드 제거
• Loop Unrolling — 루프 반복을 펼쳐서 브랜치 오버헤드 제거
• Escape Analysis — 객체가 메서드 밖으로 나가지 않으면 스택에 할당

Garbage Collector (GC)

Heap에서 더 이상 참조되지 않는 객체를 찾아서 메모리를 회수한다. 이건 주제가 너무 넓어서 별도로 정리할 내용이지만, Execution Engine의 구성 요소라는 점은 알고 있어야 한다.

간단하게만 짚으면:

# GC 종류 선택
java -XX:+UseG1GC -jar app.jar        # G1 GC (Java 9+ 기본)
java -XX:+UseZGC -jar app.jar          # ZGC (저지연)
java -XX:+UseShenandoahGC -jar app.jar # Shenandoah GC

GC가 동작할 때 Stop-the-World(STW) 이벤트가 발생한다. 모든 애플리케이션 스레드가 멈추고 GC 스레드만 작동한다. 최신 GC(ZGC, Shenandoah)는 이 STW 시간을 최소화하는 데 초점을 맞추고 있다.

바이트코드 실행 흐름 요약

전체 흐름을 하나로 이으면 이렇다:

.java 파일
  → javac (컴파일) → .class 파일 (바이트코드)
  → Class Loader (Loading → Linking → Initialization)
  → Method Area에 클래스 정보 저장
  → Execution Engine (Interpreter / JIT)이 바이트코드 실행
  → GC가 Heap의 미사용 객체 정리

JVM의 강점은 이 구조 덕분에 Write Once, Run Anywhere가 가능하다는 것이다. .class 파일은 플랫폼에 독립적이고, 각 OS별 JVM이 해당 플랫폼에 맞게 실행을 처리한다.

다음 편에서는 JVM 내부의 스레드 종류와 Stack Frame의 세부 구조를 정리한다.

참고

• JVM Internals — James D Bloom
• The Java Virtual Machine Specification (Java SE 17)

토스페이먼츠 연동 결제 시스템에서 동시에 동일한 결제 요청이 여러 번 들어오면 어떤 일이 벌어지는가?

클라이언트의 네트워크 타임아웃, 버튼 더블 클릭, 혹은 로드밸런서 재시도 등으로 동일한 결제 요청이 여러 번 서버에 도달할 수 있다. 멱등성 처리가 없다면 모든 요청이 PG사에 승인 요청으로 들어간다.

이 테스트의 목적은 단순하다:

“보호 장치 없이 100개의 동시 결제 요청을 보내면, 정확히 어떤 데이터 불일치가 발생하는가?”

Action

시스템 아키텍처 — 보호 없는 결제 흐름

V1 confirm 메서드는 어떤 멱등성 체크도 없이, 요청이 들어오면 즉시 PG에 승인을 요청한다.

public ApiResponse confirmNoIdempotency(PaymentRequest paymentRequest, Long id) {
    // 멱등성 체크 없음 — 모든 요청이 그대로 PG로 전달
    boolean confirm = paymentClient.confirm(paymentRequest);
    if (confirm) {
        paymentFacade.processConfirm(paymentRequest, id);
    }
    return ApiStatusResponse.of(Status.SUCCESS);
}

Redis 체크도 없고, DB 중복 확인도 없다. 100개의 스레드가 동시에 이 메서드를 호출하면, 100개가 모두 paymentClient.confirm()에 도달한다.

테스트 코드 — 100개의 스레드 동시 요청

@Test
@DisplayName("V1: 멱등성 없음 — 동시 100건 요청 시 중복 결제 발생")
void v1_noIdempotency_concurrentRequests() throws InterruptedException {
    int threadCount = 100;
    ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
    CountDownLatch latch = new CountDownLatch(threadCount);
    AtomicInteger successCount = new AtomicInteger(0);
    AtomicInteger failCount = new AtomicInteger(0);

    String body = """
            {
                "paymentKey": "paymentKey1",
                "orderId": "order1",
                "amount": 10000
            }
            """;

    for (int i = 0; i < threadCount; i++) {
        executorService.submit(() -> {
            try {
                // 동일한 paymentKey로 100개 동시 요청
                int status = sendConfirmRequest("/api/v1/confirm", body);
                if (status == 200) successCount.incrementAndGet();
                else failCount.incrementAndGet();
            } finally {
                latch.countDown();
            }
        });
    }
    latch.await();
}

100개의 스레드가 동일한 paymentKey1으로 동시에 /api/v1/confirm을 호출한다. CountDownLatch로 모든 스레드가 완료될 때까지 대기한다.

Result

테스트 실행 결과

IntelliJ 테스트 콘솔에서 확인된 결과:

• 성공: 1건, 실패: 99건
• 실패 원인: 404 Not Found Temp Payment — 첫 번째 요청이 TempPayment를 삭제한 후, 나머지 99개의 요청이 TempPayment를 찾지 못해 실패

언뜻 보면 “1건만 성공했으니 문제 없는 것 아닌가?”라고 생각할 수 있다. 하지만 PG서버 쪽 기록을 보면 상황이 다르다.

PG 서버 DB — 100건 저장

mock PG 서버의 payment 테이블에는 동일한 paymentKey1으로 100건이 저장되어 있다. 모든 요청이 PG 승인까지 도달했다는 뜻이다. PG 서버 입장에서는 100번의 결제 승인이 발생한 것이다.

실제 DB — 1건 저장

실제 서비스 DB의 payment 테이블에는 1건만 COMPLETE 상태로 저장되어 있다.

데이터 불일치의 본질

PG에서는 100번 돈을 빼갔는데, 서비스에는 1건만 기록되어 있다. 99건의 결제가 유령 결제가 된 것이다. 실제 운영 환경이었다면 유저의 돈은 100번 빠져나가고, 서비스에는 1건만 반영되는 치명적인 상황이다.

Reflection

이 테스트가 증명하는 것은 단순하다: 멱등성 없는 결제 시스템은 동시 요청에 취약하다.

흥미로운 점은 서버 응답만 보면 “1건 성공, 99건 실패”로 문제가 없어 보인다는 것이다. 하지만 실패 응답이 돌아오기 전에 PG 승인은 이미 완료된 상태다. HTTP 응답 코드가 실패라고 해서 PG 승인이 취소되는 것이 아니다.

결제 시스템의 정합성은 우리 서버의 응답이 아니라, PG 서버의 상태를 기준으로 판단해야 한다. 이 간극을 메우는 것이 멱등성의 역할이다.

PG에 100번 요청이 들어가는 것 자체를 막아야 한다. 첫 번째 요청만 통과시키고 나머지는 차단하려면? 2단계: Redis setIfAbsent로 동시 요청 차단 →

1단계에서 멱등성 없이 100개의 스레드를 보내면 PG에 100건이 승인되는 것을 확인했다. 해결책은 명확하다 — 첫 번째 요청만 PG에 전달하고, 나머지는 차단해야 한다.

Redis의 setIfAbsent(SETNX)는 원자적 연산이다. 동시에 100개의 요청이 들어와도 딱 하나만 true를 반환한다. Redis 단일 스레드 특성상 경쟁 조건이 발생하지 않는다.

하지만 질문이 남는다:

“Redis가 정상일 때는 완벽하다. 그런데 Redis가 내려가면?”

이 테스트는 두 가지를 검증한다:

1. Redis가 정상일 때 멱등성이 동작하는가
2. Redis가 장애일 때 무슨 일이 벌어지는가

Action

시스템 아키텍처 — Redis 멱등성과 장애 시나리오

V2 코드: Redis 멱등성 + 장애 시 스킵

public ApiResponse confirmRedisFail(String idempotencyKey,
                                     PaymentRequest paymentRequest, Long id) {
    try {
        if (!idempotencyRedisManager.tryAcquire(idempotencyKey)) {
            throw new CommonException(Status.ALREADY_PAYMENT_REQUEST);
        }
    } catch (CommonException e) {
        throw e;  // 이미 처리된 요청 — 그대로 거부
    } catch (Exception e) {
        // Redis 장애 시 — 멱등성 체크를 건너뛴다
        log.warn("[V2] Redis 장애 발생 - 멱등성 체크 스킵. key={}", idempotencyKey);
    }

    boolean confirm = paymentClient.confirm(paymentRequest);
    if (confirm) {
        paymentFacade.processConfirm(paymentRequest, id);
    }
    return ApiStatusResponse.of(Status.SUCCESS);
}

핵심은 catch (Exception e) 블록이다. Redis 연결 실패, 타임아웃 등 Redis 관련 예외가 발생하면 경고 로그만 남기고 결제를 진행한다. “Redis가 죽었으니 결제도 안 되면 안 되지 않나?”라는 판단이다.

IdempotencyRedisManager — 원자적 락 획득

public boolean tryAcquire(String key) {
    Boolean result = redisTemplate.opsForValue()
        .setIfAbsent(key, IdempotencyStatus.PROCESSING.name(),
                     Duration.ofHours(24));
    if (result == null) {
        throw new CommonException(Status.REDIS_SERVER_ERROR);
    }
    return result;  // true: 첫 요청, false: 중복 요청
}

public void complete(String key) {
    redisTemplate.opsForValue().set(key, IdempotencyStatus.COMPLETED.name());
}

public void fail(String key) {
    redisTemplate.delete(key);  // 키 삭제 → 재시도 허용
}

• tryAcquire(): SETNX + 24시간 TTL. 첫 요청만 true.
• complete(): 성공 시 상태를 COMPLETED로 변경
• fail(): 실패 시 키를 삭제하여 재시도를 허용

테스트 1: Redis 정상 — 100개의 스레드 동시 요청

@Test
@DisplayName("V2: Redis 정상 — 동시 100건 중 1건만 PG 호출")
void v2_redisNormal_concurrentRequests() throws InterruptedException {
    int threadCount = 100;
    ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
    CountDownLatch latch = new CountDownLatch(threadCount);

    for (int i = 0; i < threadCount; i++) {
        executorService.submit(() -> {
            try {
                sendConfirmRequest("/api/v2/confirm", body, "paymentKey1");
            } finally {
                latch.countDown();
            }
        });
    }
    latch.await();
}

100개의 스레드가 동일한 Idempotency-Key: paymentKey1로 동시 요청한다.

테스트 2: Redis 장애 시뮬레이션

@Test
@DisplayName("V2: Redis 장애 — 멱등성 뚫림 확인")
void v2_redisFailure_concurrentRequests() throws InterruptedException {
    // Phase 1: Redis 정상 — 50개의 스레드
    // → 1건만 PG 도달

    Thread.sleep(10000);  // Redis 수동 중지

    // Phase 2: Redis DOWN — 50개의 스레드
    // → catch 블록에서 스킵 → 전부 PG 도달
}

Phase 1에서 50개의 스레드를 보내고, Redis를 수동으로 중지한 후 Phase 2에서 50개의 스레드를 추가로 보낸다.

Result

테스트 1 결과: Redis 정상

mock PG 서버에 1건만 저장. Redis setIfAbsent가 99개의 중복 요청을 완벽하게 차단했다.

실제 DB의 point 테이블에도 정상적으로 10,000원이 적립됐다. V1에서 발생했던 데이터 불일치가 완전히 해소됐다.

테스트 2 결과: Redis 장애

Redis가 내려간 Phase 2에서는:

• [V2] Redis 장애 발생 - 멱등성 체크 스킵 경고 로그 출력
• 모든 요청이 catch (Exception e) 블록을 타고 PG까지 도달
• 성공 1건, 실패 99건 (V1과 동일한 패턴)

결론: Redis가 죽으면 V1과 동일한 상황이 재현된다. Redis가 단일 장애점(SPOF)이 된 것이다.

왜 catch에서 결제를 진행하는가?

“Redis 장애 시 결제를 차단하면 되지 않나?”라는 의문이 들 수 있다. 하지만 Redis 장애 때문에 결제 자체가 불가능해지면, 그것은 또 다른 장애다. 가용성과 정합성 사이의 트레이드오프에서, V2는 가용성을 선택하고 정합성을 희생한 것이다.

Reflection

V2가 증명한 것은 두 가지다:

1. Redis 멱등성은 동작한다. setIfAbsent의 원자성 덕분에 100개의 동시 요청 중 단 1건만 통과시키는 것이 가능하다. 정상 상황에서는 완벽한 해결책이다.

2. Redis는 단일 장애점이 된다. Redis에 의존하는 모든 보호 장치는 Redis와 함께 사라진다. catch 블록에서 “일단 진행”하는 판단은 가용성을 지키지만, 결제 정합성이라는 핵심 가치를 포기한 것이다.

결제 시스템에서 정합성을 포기하는 것은 허용되지 않는다. Redis가 죽어도 멱등성이 보장되려면, Redis가 아닌 다른 곳에도 멱등성 상태를 저장해야 한다. 그것이 DB다.

하지만 그 전에 먼저 검증할 것이 있다 — PG 승인까지 성공했는데 DB 저장이 실패하면? 이 시나리오를 의도적으로 만들어 Webhook이 복구할 수 있는지 테스트해야 한다.

Redis 멱등성은 정상 시 완벽하지만 SPOF 문제가 있다. 그런데 더 근본적인 질문 — PG 승인 후 DB 저장 자체가 실패하면? 3단계: DB 저장 실패 시 Webhook이 복구할 수 있는가 →

2단계에서 Redis 멱등성이 정상 시 동작하는 것을 확인했다. 하지만 결제 흐름에는 또 다른 위험 구간이 존재한다.

클라이언트 → 서버 → Redis 체크 ✓ → PG 승인 ✓ → DB 저장 ???

PG 승인까지 성공한 시점에서 서버가 죽거나 DB 커넥션이 끊기면, Payment가 저장되지 않는다. 유저의 돈은 빠져나갔는데 서비스에는 기록이 없는 결제 유실이 발생한다.

토스페이먼츠는 결제 승인 후 Webhook으로 결과를 통보한다. 이 Webhook이 결제 유실을 복구할 수 있는지 테스트해야 한다.

“PG 승인은 됐는데 DB 저장이 실패하면, Webhook만으로 복구가 되는가?”

이 질문에 답하기 위해, 의도적으로 DB 저장을 스킵하고 Webhook 복구를 검증했다.

Action

시스템 아키텍처 — DB 스킵 + Webhook 복구 흐름

V3 코드: 의도적 DB 저장 스킵

public ApiResponse confirmNoDbSave(String idempotencyKey,
                                    PaymentRequest paymentRequest, Long id) {
    if (!idempotencyRedisManager.tryAcquire(idempotencyKey)) {
        throw new CommonException(Status.ALREADY_PAYMENT_REQUEST);
    }

    log.warn("[NO_DB_SAVE] DB 멱등성 저장 스킵 - 웹훅으로 보완 필요. key={}", idempotencyKey);

    boolean confirm = paymentClient.confirm(paymentRequest);
    if (confirm) {
        // 핵심: processConfirm()을 호출하지 않는다
        // → Payment 미생성, 포인트 미적립, TempPayment 미삭제
        idempotencyRedisManager.complete(idempotencyKey);
    } else {
        idempotencyRedisManager.fail(idempotencyKey);
    }
    return ApiStatusResponse.of(Status.SUCCESS);
}

paymentFacade.processConfirm()을 의도적으로 호출하지 않는다. PG 승인은 성공하지만:

• Payment 레코드 미생성
• 포인트 미적립
• TempPayment는 PENDING 상태 그대로

실제 운영에서 DB 장애가 발생한 상황을 시뮬레이션한 것이다.

Webhook 복구 로직: WebHookService

PG가 결제 완료를 Webhook으로 통보하면, WebHookService가 복구를 시도한다.

@Service
public class WebHookService {

    public void processWebHook(JsonNode jsonNode) {
        JsonNode data = jsonNode.get("data");
        String status = data.get("status").asText();
        String paymentKey = data.get("paymentKey").asText();
        String orderId = data.get("orderId").asText();
        long amount = Long.parseLong(data.get("totalAmount").asText());

        // 1. DONE이 아닌 상태는 무시
        if (!status.equals("DONE")) {
            webHookHistoryRepository.save(
                WebHookHistory.of(paymentKey, orderId, amount, status, false));
            return;
        }

        // 2. 이미 처리된 Webhook인지 확인 (멱등성)
        Optional<WebHookHistory> processed =
            webHookHistoryRepository.findByPaymentKeyAndProcessedTrue(paymentKey);
        if (processed.isPresent()) return;

        // 3. TempPayment 조회 (결제 의도 확인)
        TempPayment tempPayment = tempPaymentRepository
            .findByPaymentKeyAndOrderIdAndAmountAndStatus(
                paymentKey, orderId, amount, PaymentStatus.PENDING)
            .orElseThrow(() -> new CommonException(Status.NOT_FOUND_TEMP_PAYMENT));

        // 4. Payment가 이미 존재하는지 확인 (confirm 경로에서 생성됐을 수 있음)
        Optional<Payment> existingPayment =
            paymentRepository.findByPaymentKeyAndOrderIdAndAmount(
                paymentKey, orderId, amount);

        // 5. Payment 미존재 시 복구
        if (existingPayment.isEmpty()) {
            Member member = memberRepository.findById(tempPayment.getMember().getId())
                .orElseThrow(() -> new CommonException(Status.NOT_FOUND_MEMBER));

            paymentRepository.save(PaymentFactory.from(paymentKey, orderId, amount, member));
            tempPaymentRepository.delete(tempPayment);

            Point point = pointRepository.findByMember(member)
                .orElseThrow(() -> new CommonException(Status.NOT_FOUND_POINT));
            point.addAmount(amount);
        }

        // 6. 처리 완료 기록
        webHookHistoryRepository.save(
            WebHookHistory.of(paymentKey, orderId, amount, status, true));
    }
}

Webhook의 멱등성은 WebHookHistory.processed 필드로 보장한다. 동일한 Webhook이 여러 번 들어와도 processed=true인 레코드가 존재하면 무시한다.

복구 흐름:

1. DONE 상태 확인
2. WebHookHistory로 중복 처리 방지
3. TempPayment(PENDING)로 결제 의도 확인
4. Payment가 없으면 생성 + 포인트 적립 + TempPayment 삭제
5. WebHookHistory에 processed=true 기록

Result

confirm 직후: Payment 0건

mock PG 서버에는 1건 저장. Redis 멱등성이 정상 동작하여 PG에는 1건만 도달했다.

temp_payment 테이블에 1건이 PENDING 상태로 남아 있다. processConfirm()을 스킵했기 때문에 TempPayment가 삭제되지 않았다.

payment 테이블은 0건. DB 저장이 스킵됐으므로 결제 완료 레코드가 없다.

이 시점에서의 상태:

• PG: 승인 완료 (돈은 빠져나감)
• 서비스 DB: 결제 기록 없음
• TempPayment: PENDING (결제 의도만 남아 있음)

결제 유실 상태다.

Webhook 수신 후: Payment 1건 복구

PG Webhook을 수신한 후, payment 테이블에 1건이 COMPLETE 상태로 생성됐다. 포인트도 10,000원이 정상 적립됐다.

Webhook이 결제 유실을 완전히 복구했다.

Reflection

이 테스트가 증명한 것은 Webhook 단독으로도 결제 유실을 복구할 수 있다는 것이다. TempPayment가 PENDING 상태로 남아 있는 한, Webhook은 결제 의도를 확인하고 Payment를 생성할 수 있다.

하지만 Webhook에는 구조적 한계가 있다:

1. PG 서버가 Webhook을 보내지 못할 수 있다 — PG 장애, 네트워크 단절
2. 우리 서버가 Webhook을 수신하지 못할 수 있다 — 서버 다운, 네트워크 이슈
3. Webhook은 PG가 주도한다 — 우리가 재시도 시점을 제어할 수 없다

Webhook은 “2층 안전망”이지만, 최종 보정은 우리 서버가 직접 PG에 조회하는 구조가 필요하다. Webhook에 의존하지 않고, 스케줄러가 PENDING 상태의 TempPayment를 주기적으로 확인하여 PG에 직접 물어보는 것이다.

Webhook으로 복구는 가능하다. 하지만 Webhook마저 안 오면? 최종 보정을 우리가 직접 해야 한다. 4단계: Redis + DB 이중 멱등성 + Reconciliation 스케줄러 →