Day 44 — 메모리 누수 진단과 JVM 튜닝

지난 시간엔 JVM 의 메모리 속을 그림으로 그렸어요. 객체는 Heap 에, 메서드의 지역 변수는 Stack 에, 클래스 설명서는 Metaspace 에 산다고 칸을 나눠봤죠. 가비지 컬렉터가 안 쓰는 객체를 자동으로 치워준다는 것, 그런데 다 쓴 객체를 계속 붙들고 있으면 누수가 생긴다는 것까지 따라갔어요. 그러면서 마지막에 약속했었죠. "실제로 메모리가 새고 있는지를 어떻게 눈으로 확인할까?" 하고요.

오늘은 그 그림을 화면 위에서 살아 움직이게 만들어 봅니다. 지난 시간엔 이론을 그림으로 그렸다면, 오늘은 그 그림이 실제로 움직이는 걸 도구로 직접 봐요. 가비지 컬렉터가 정말 도는지 기록을 들여다보고, 누수를 일으키는 객체가 메모리에 쌓이는 걸 그래프로 잡아내고, 끝내 그 범인이 누구인지 이름까지 알아낼 거예요.

흐름은 이래요. 먼저 JVM 에게 "메모리를 이만큼만 써라" 라고 지시하는 옵션부터 익혀요. 그다음 가비지 컬렉터가 돌 때마다 남기는 기록(로그)을 읽는 법을 배우고, VisualVM 이라는 무료 도구로 Heap 을 실시간 그래프로 들여다봅니다. 그러고 나서 지난 시간 만들었던 누수 코드를 실제로 다시 돌려서 메모리가 차오르는 걸 눈으로 확인하고, 그 순간의 Heap 을 통째로 떠내서(덤프) 범인 객체를 찾아낸 다음, 마지막에 누수를 고쳐서 그래프가 평평해지는 것까지 확인하면 끝이에요.

오늘은 새 문법을 배우는 날이 아니라, 지금까지 짠 코드가 메모리에서 어떻게 동작하는지를 도구로 진단하는 실전 정비공의 하루 예요. 자동차 보닛을 열고 계기판을 들여다보는 정비사처럼, JVM 의 보닛을 열어봅시다.

🎯 학습 목표

• JVM 에게 힙 크기를 지시하는 -Xmx·-Xms·-Xmn 옵션을 설정할 수 있어요.
• 가비지 컬렉터가 남기는 GC 로그(-Xlog:gc*)를 읽고 무슨 일이 일어났는지 해석할 수 있어요.
• VisualVM 으로 실행 중인 프로그램의 Heap 을 실시간 그래프로 모니터링할 수 있어요.
• 메모리 누수를 실제로 재현하고, Heap 덤프를 떠서 어떤 객체가 안 죽고 쌓였는지 진단할 수 있어요.
• 상황(메모리가 빠듯한 서버, 누수 진단 등)에 맞게 어떤 옵션을 줄지 판단할 수 있어요.

Step 1: JVM 메모리 옵션 — 힙 크기를 직접 정하기

지난 시간 우리는 JVM 메모리가 Heap·Stack·Metaspace 세 구역으로 나뉜다고 배웠어요. 그중에서 우리가 new 로 만든 객체들이 사는 곳이 Heap 이었죠. 그런데 이 Heap 이 정확히 얼마나 큰지는 한 번도 정해본 적이 없어요. 그동안은 JVM 이 알아서 적당한 크기로 잡아줬거든요.

오늘 첫 도구는 바로 이거예요. "Heap 을 얼마나 크게 쓸지 우리가 직접 정해주는 것." JVM 에게 메모리 크기를 지시하는 가장 기본적인 손잡이예요.

왜 크기를 정해야 할까

먼저 "왜" 부터 짚어볼게요. Heap 크기를 잘못 잡으면 어떤 일이 벌어질까요? 두 방향 다 문제예요.

Heap 이 너무 작으면, 객체를 만들다가 공간이 가득 차요. 그러면 JVM 은 더 이상 객체를 못 만들고 OutOfMemoryError(메모리 부족 에러)를 던지면서 프로그램이 그대로 죽어버려요. 지난 시간 누수 이야기에서 잠깐 봤던 그 에러예요.

반대로 너무 크면, 안 쓰는 메모리를 컴퓨터에서 잔뜩 빌려놓고 낭비하게 돼요. 게다가 Heap 이 클수록 가비지 컬렉터가 한 번 청소할 때 훑어야 할 양이 많아져서, 청소하는 동안 프로그램이 잠깐 멈추는 시간이 길어질 수도 있어요.

그래서 "너무 작지도 크지도 않게, 딱 적당히" 를 우리가 지정해 주는 거예요.

같은 양의 객체가 들어가도, 힙을 작게 잡으면 금방 꽉 차고 크게 잡으면 헐렁해요.

[██████████]  ← 너무 작게 잡음: 꽉 참 → OutOfMemoryError (객체 못 만들고 죽음)
[██████    ]  ← 적당히 잡음: 여유 있음 → 가장 좋은 상태
[███       ]  ← 너무 크게 잡음: 텅텅 → 메모리 낭비 + 청소 시 멈춤이 길어짐

옵션 세 가지

크기를 정하는 손잡이는 세 개예요. 이름이 좀 암호 같지만, 뜻을 알면 외우기 쉬워요.

-Xmx 는 힙의 최대(max) 크기예요. 끝에 mx 가 붙죠. "여기까지만 커질 수 있어" 라는 천장이에요. 예를 들어 -Xmx512m 이라고 주면 힙이 최대 512메가바이트까지만 자라고, 그걸 넘으면 OutOfMemoryError 가 나요. -Xmx2g 라고 주면 최대 2기가바이트까지 허용한다는 뜻이에요.

-Xms 는 힙의 시작(start) 크기예요. 끝에 ms 가 붙죠. JVM 이 켜질 때 처음부터 확보해두는 크기예요. -Xms256m 이라고 주면 시작하자마자 256메가바이트를 잡아두고 출발해요. 객체가 점점 늘어나서 이 크기를 넘으면 힙이 -Xmx 까지 천천히 자라나요.

한 가지 팁을 드리면, 시작 크기와 최대 크기를 같게 두는 경우가 많아요. -Xms512m -Xmx512m 처럼요. 이러면 힙이 도중에 늘었다 줄었다 하느라 생기는 출렁임이 없어서 더 안정적으로 동작해요.

-Xmn 은 young(젊은) 영역 의 크기예요. 지난 시간 가비지 컬렉션을 배울 때, 갓 만들어진 객체들이 잠깐 머무는 "젊은 구역" 이야기가 나왔던 거 기억나세요? 그 젊은 구역의 크기를 따로 정하는 옵션이에요. 지금은 "이런 것도 있구나" 정도만 알아두면 충분해요. 평소엔 거의 건드릴 일이 없고, 성능을 아주 깊게 튜닝할 때나 꺼내 쓰는 손잡이예요.

크기 뒤에 붙이는 단위는 세 가지예요. k 는 킬로바이트, m 은 메가바이트, g 는 기가바이트. 그래서 -Xmx2g 는 "최대 2기가" 이고 -Xms256m 은 "시작 256메가" 인 거죠.

IntelliJ 에서 설정하는 법

그럼 이 옵션들을 어디에 적을까요? 우리는 평소처럼 IntelliJ 에서 "Run" 버튼으로 프로그램을 실행하니까, IntelliJ 안에서 설정해 줄게요.

상단 메뉴에서 Run → Edit Configurations 로 들어가면 실행 설정 창이 열려요. 거기에 VM options 라는 입력 칸이 있어요. 그 칸에 옵션을 띄어쓰기로 나열해서 적어주면 돼요. 예를 들면 이렇게요.

-Xmx512m -Xms256m

이렇게 적고 실행하면, 우리 프로그램은 256메가로 시작해서 최대 512메가까지 쓸 수 있는 힙을 가지고 돌아가요.

⚠️ 헷갈리기 쉬운 함정 하나만 짚을게요. IntelliJ 메뉴를 뒤지다 보면 Help → Edit Custom VM Options 라는 비슷한 이름의 메뉴가 보일 수 있어요. 그건 IntelliJ 자기 자신 이 쓰는 메모리를 정하는 설정이라, 우리가 실행할 프로그램과는 상관없어요. 우리가 건드릴 건 어디까지나 Run Configuration 의 VM options 칸 이에요. 내가 실행할 프로그램의 힙을 정하는 거니까요.

터미널에서 직접 실행한다면 명령 한 줄로도 줄 수 있어요. java -Xmx512m -Xms256m MainClass 처럼 클래스 이름 앞에 옵션을 붙이면 돼요. 다만 우리는 IntelliJ 로 실습하니, 이 방법은 "이렇게도 된다" 정도로만 기억해두세요.

💡 오늘 기억할 한 줄: -Xmx 는 힙의 최대 크기, -Xms 는 힙의 시작 크기. 끝글자 mx(max)·ms(start)로 외우면 안 헷갈려요. 평소엔 기본값으로 충분하고, 메모리가 빠듯하거나 누수를 진단할 때 직접 정해주면 돼요.

Step 2: GC 로그 읽기 — 가비지 컬렉터의 작업 일지

지난 시간, 가비지 컬렉터가 안 쓰는 객체를 알아서 치워준다고 배웠죠. 그런데 그 청소가 언제, 얼마나 자주, 한 번에 얼마나 일어나는지는 한 번도 본 적이 없어요. 청소부가 보이지 않는 곳에서 조용히 일하고 있었던 거예요.

JVM 에게 "청소할 때마다 일지를 남겨줘" 라고 부탁하면, 그 작업 기록을 우리가 직접 볼 수 있어요. 이 기록을 GC 로그(log, 기록) 라고 불러요. 로그란 프로그램이 동작하면서 남기는 일지 같은 거예요.

로그 켜기

GC 로그를 켜는 옵션은 -Xlog:gc* 예요. Step 1 에서 옵션을 적었던 그 VM options 칸에 똑같이 적어주면 돼요.

• -Xlog:gc — GC 가 일어날 때마다 핵심을 한 줄씩 남겨요.
• -Xlog:gc* — 끝에 별표(*)를 붙이면 GC 와 관련된 더 자세한 항목까지 남겨요. 별표는 "gc 로 시작하는 모든 기록" 이라는 뜻이에요.

이대로 두면 로그가 화면(콘솔)에 주르륵 찍혀요. 파일로 따로 모으고 싶으면 뒤에 저장할 파일 이름을 붙여요.

-Xlog:gc*:file=gc.log

이러면 gc.log 라는 파일에 기록이 차곡차곡 쌓여서, 나중에 천천히 열어볼 수 있어요.

로그 한 줄 읽는 법

옵션을 켜고 프로그램을 돌리면 이런 줄들이 찍혀요. 실제로 찍힌 한 줄을 가져와 봤어요.

[0.284s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 116M->34M(256M) 2.678ms

암호처럼 보이지만, 우리가 꼭 읽어야 할 핵심은 뒤쪽 네 덩어리뿐이에요.

GC(1)          ← 1번째 청소 (전체에서 몇 번째 GC인지)
Pause Young    ← 젊은 객체만 훑는 작은 청소
116M->34M      ← 청소 전 116메가 → 청소 후 34메가 (82메가어치 회수!)
(256M)         ← 전체 힙 크기는 256메가
2.678ms        ← 이 청소에 걸린 시간

정리하면 이래요. 1번째 청소가 일어났고, 청소 전엔 힙을 116메가 쓰고 있었는데 청소 후 34메가로 줄었다. 전체 힙은 256메가이고, 청소에 2.678밀리초가 걸렸다. 116메가에서 34메가로 뚝 떨어진 게 보이죠? 가비지 컬렉터가 안 쓰는 객체 82메가어치를 치워준 거예요. 이게 건강하게 돌아가는 GC 의 모습이에요.

Young GC 와 Full GC

로그를 보다 보면 두 종류의 청소가 보여요.

• Young GC — 갓 만들어진 "젊은" 객체들만 빠르게 훑는 작은 청소예요. 자주 일어나고, 위 예시처럼 보통 몇 밀리초 만에 끝나요.
• Full GC — 힙 전체를 훑는 큰 청소예요. 가끔 일어나고, 훑을 양이 많아 더 오래 걸려요.

지난 시간 배운 Mark(표시) → Sweep(쓸기) → Compact(정리) 한 바퀴가, 로그에서는 이렇게 한 줄로 압축돼서 찍히는 거예요. 평소엔 빠른 Young GC 가 대부분이고, Full GC 가 자주 길게 보이기 시작하면 "메모리가 빡빡하구나" 하는 신호로 읽을 수 있어요.

💡 오늘 기억할 한 줄: GC 로그에서 116M->34M(256M) 만 읽을 줄 알아도 절반은 한 거예요. 청소 전 → 청소 후 (전체 힙) 순서니까요. 만약 화살표 뒤 숫자가 청소를 해도 계속 안 줄어든다면, 메모리 누수를 의심해 봐야 해요.

Step 3: VisualVM — Heap 을 실시간 그래프로 보기

GC 로그는 훌륭한 일지지만, 텍스트라서 흐름을 한눈에 잡기는 어려워요. 숫자가 줄줄이 찍히면 "지금 메모리가 늘고 있는 건가 줄고 있는 건가?" 가 잘 안 보이죠. 같은 정보를 실시간 그래프 로 보여주는 도구가 있으면 훨씬 직관적이에요. 그게 바로 VisualVM 이에요.

VisualVM 은 실행 중인 자바 프로그램의 속을 들여다보는 무료 도구예요. 지금 메모리를 얼마나 쓰는지, 가비지 컬렉터가 언제 도는지를 그래프로 실시간으로 보여줘요.

받아서 켜기

VisualVM 은 예전엔 JDK 안에 같이 들어 있었는데, 지금은 따로 떨어져 나와서 직접 받아야 해요. visualvm.github.io 에서 내려받을 수 있고, 글을 쓰는 지금 기준 최신은 2.2.1 버전이라 JDK 25 까지 잘 맞아요. 받아서 압축을 풀고 실행하면 돼요.

켜면 왼쪽에 지금 내 컴퓨터에서 돌아가는 자바 프로그램 목록 이 나와요. 우리가 IntelliJ 로 프로그램을 실행해 두면, 그 프로그램이 목록에 뜨죠. 그걸 더블클릭하면 속을 들여다보는 화면이 열려요. 거기서 Monitor 탭을 누르면 Heap 사용량 그래프가 실시간으로 그려져요.

그래프 모양으로 상태 읽기

건강한 프로그램의 Heap 그래프는 톱니 모양 이에요.

힙 사용량
 │    /|    /|    /|
 │   / |   / |   / |     ← 객체가 쌓이며 위로 올라가다가
 │  /  |  /  |  /  |
 │ /   |_/   |_/   |__   ← 가비지 컬렉터가 치우면 뚝 떨어지고, 다시 반복
 └─────────────────────  시간

객체가 쌓이며 그래프가 올라가다가, 가비지 컬렉터가 한 번 치우면 뚝 떨어지고, 또 쌓이다가 떨어지고. 이 오르내림이 반복되는 톱니 모양이면 "잘 청소되고 있구나" 하고 안심해도 돼요. 우리가 Step 2 로그에서 본 116M->34M 한 줄이, 그래프에서는 한 번의 "뚝 떨어짐" 으로 보이는 거예요.

문제는 그래프가 톱니가 아니라 한 방향으로 계단처럼 계속 올라가기만 할 때예요. 치워도 안 내려가고 우상향한다면, 누군가 객체를 안 놓고 붙들고 있다는 신호예요. 다음 Step 에서 바로 그 모습을 직접 만들어 볼 거예요.

Step 4: 메모리 누수를 눈으로 보기 — 누수 재현하기

이제 지난 시간 이론으로만 봤던 메모리 누수를, 실제로 돌려서 눈으로 잡아볼 차례예요. Day 43 에서 만들었던 구독 등록부 SubscriptionRegistry 를 기억하시죠? 구독자를 subscribe() 로 더하기만 하고 unsubscribe() 로 빼지 않으면, 리스트가 구독자를 계속 붙들고 있어서 누수가 난다고 했어요.

그 누수를 일부러 일으키는 작은 프로그램을 하나 준비했어요.

// com/instagram/javabasic/jvm/MemoryLeakDemo.java

public class MemoryLeakDemo {

    // 구독만 하고 해지를 한 번도 안 하는 누수 버전이에요.
    public static SubscriptionRegistry leakWithoutUnsubscribe(int rounds) {
        SubscriptionRegistry registry = new SubscriptionRegistry();
        for (int i = 0; i < rounds; i++) {
            // 구독만 하고 해지는 하지 않아요. 그래서 구독자가 계속 누적돼요.
            registry.subscribe(new NamedSubscriber("subscriber-" + i));
        }
        return registry;
    }

    // VisualVM 으로 Heap 이 차오르는 모습을 관찰할 때 실행하는 데모예요.
    public static void main(String[] args) {
        SubscriptionRegistry registry = new SubscriptionRegistry();
        long total = 0;
        while (true) {
            // 한 라운드에 10만 명씩 등록부에 쌓아요. 해지는 하지 않아요.
            for (int i = 0; i < 100_000; i++) {
                registry.subscribe(new NamedSubscriber("subscriber-" + i));
            }
            total += 100_000;
            System.out.println("지금까지 쌓인 구독자 수: " + total);
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                return;
            }
        }
    }
}

main 이 하는 일은 단순해요. 끝없는 반복 안에서 구독자를 10만 명씩 등록부에 쌓고, 잠깐 쉬고, 또 쌓아요. 해지는 한 번도 안 하니까 구독자가 영원히 늘어나기만 하죠. 중간에 Thread.sleep 으로 잠깐 멈추는 건, VisualVM 이 그래프를 그릴 틈을 주려는 거예요.

돌려보면 무슨 일이 벌어질까

이 main 을 힙을 일부러 작게 잡고(-Xmx64m) GC 로그를 켜서 돌려봤어요. 누수가 빨리 드러나게 하려고 힙을 좁게 준 거예요. 그랬더니 로그에 이런 줄들이 찍혔어요.

[2.121s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure: Allocation) 42M->43M(64M) 56.261ms
[2.641s][info][gc] GC(1) Pause Young (Concurrent Start) (G1 Humongous Allocation) 48M->46M(64M) 17.426ms

Step 2 의 건강한 줄 116M->34M 과 비교해 보세요. 그땐 청소 후 숫자가 뚝 떨어졌는데, 여기선 42M->43M, 48M->46M 처럼 청소를 해도 거의 안 줄거나 오히려 늘어요. 첫 줄 끝에 붙은 Evacuation Failure(대피 실패) 는 "치울 데가 없어 청소에 실패했다" 는 뜻이에요. 가비지 컬렉터가 열심히 돌긴 도는데, 치울 수 있는 게 없는 거죠. 등록부 리스트가 구독자를 전부 강하게 붙들고 있으니까요.

이 순간 VisualVM 그래프를 같이 띄워두면, 톱니가 아니라 계단처럼 끝없이 우상향하는 선 이 그려져요. 한참 지켜보다 GC 버튼을 직접 눌러봐도 그래프는 거의 안 내려가요. 그러다 힙이 꽉 차면 결국 OutOfMemoryError 로 프로그램이 멈춰요. Day 43 에서 "강한 참조가 객체를 붙들면 청소 못 한다" 던 그 경고가, 화면 위에서 실제로 일어나는 모습을 본 거예요.

힙 사용량
 │                  ___／   ← 치워도 안 내려가고
 │             ___／         계단처럼 계속 올라가다가
 │        ___／
 │   ___／                   ← 끝내 꽉 차서 OutOfMemoryError
 └─────────────────────────  시간

💡 오늘 기억할 한 줄: 그래프가 톱니면 건강, 우상향 계단이면 누수 예요. GC 로그에서 화살표 뒤 숫자(-> 다음)가 청소를 거듭해도 안 줄어들면, 어딘가에서 객체를 안 놓고 있다는 뜻이에요.

Step 5: Heap 덤프 — 그 순간의 메모리를 통째로 떠내기

그래프가 우상향한다는 것까진 알았어요. 그런데 "메모리가 새고 있다" 까지만으론 부족해요. 정확히 어떤 객체가 안 죽고 쌓이는지를 알아야 고칠 수 있죠. 그러려면 그 순간 힙 안에 무슨 객체가 몇 개나 들어 있는지 들여다봐야 해요.

이때 쓰는 게 Heap 덤프(heap dump) 예요. 덤프란 그 순간 힙에 살아 있는 모든 객체를 통째로 떠낸 메모리 사진 이에요. 사진을 찍어두면 멈춰 세운 화면을 천천히 뜯어볼 수 있잖아요. 그것처럼 메모리를 한 장 찍어서 분석하는 거예요.

덤프 뜨는 법

VisualVM 에서 왼쪽 프로그램 목록의 내 프로그램을 우클릭하면 Heap Dump 메뉴가 있어요. 그걸 누르면 그 순간의 힙을 통째로 떠서 화면에 열어줘요. (떠낸 사진은 .hprof 라는 파일로 저장돼요.)

터미널을 더 좋아한다면 명령으로도 뜰 수 있어요. 프로그램의 번호(PID)를 알아내서 jcmd <번호> GC.heap_dump heap.hprof 라고 치면 heap.hprof 파일이 만들어져요. 다만 우리는 VisualVM 으로 실습하니, 이건 "이렇게도 된다" 정도로 알아두세요.

사진 속에서 범인 찾기

덤프를 열면 어떤 클래스의 객체가 몇 개나 있는지 를 개수 순으로 정렬해서 볼 수 있어요. 누수가 난 우리 프로그램의 덤프를 열어봤더니, 이런 모습이 보였어요.

NamedSubscriber 가 무려 120만 개! 그리고 그 구독자마다 이름(String)을 하나씩 들고 있으니 String 도 그만큼 많죠. 평범한 프로그램이라면 이렇게 한 종류의 객체가 수백만 개씩 쌓일 일이 없어요. 압도적으로 많은 이 객체가 바로 범인 후보 예요. 우리가 Day 43 에서 만든 그 구독자가, 안 죽고 이만큼 쌓여 있던 거예요.

💡 오늘 기억할 한 줄: 누수가 의심되면 Heap 덤프를 떠서 "비정상적으로 많이 쌓인 클래스" 를 찾으세요. 개수가 압도적인 객체가 거의 항상 범인이에요.

Step 6: 참조 그래프 — 누가 이 객체를 안 놓고 있나

범인 후보는 찾았어요. NamedSubscriber 120만 개. 그런데 한 가지가 더 궁금해요. 왜 가비지 컬렉터는 이걸 안 치웠을까? Day 43 에서 배운 규칙을 떠올려보세요. "뿌리(GC Root)에서 화살표로 닿을 수 있으면 살아 있는 객체" 였죠. 그러니 이 120만 개도 어딘가 뿌리에서 화살표가 닿고 있다는 뜻이에요. 그 화살표를 따라가면 진짜 원인이 나와요.

VisualVM 덤프 화면에서 객체 하나를 골라 "이걸 누가 붙들고 있나(가장 가까운 GC Root 까지의 경로)" 를 보여달라고 하면, 이런 사슬이 그려져요.

GC Root (프로그램이 살아 있는 동안 유지되는 뿌리)
   │  붙들고 있음
   ▼
SubscriptionRegistry 객체
   │  subscribers 라는 리스트 필드가
   ▼
ArrayList ── [구독자][구독자][구독자] … 120만 개를 줄줄이 붙듦

읽어보면 이래요. 뿌리에서 시작한 화살표가 SubscriptionRegistry 로 닿고, 그 안의 subscribers 리스트가 구독자 120만 개를 하나하나 붙들고 있어요. 이 사슬이 끊기지 않고 이어져 있으니, 가비지 컬렉터 입장에선 전부 "아직 쓰는 객체" 로 보여서 손을 못 대는 거예요.

여기서 중요한 깨달음이 하나 있어요. 진짜 범인은 NamedSubscriber 자체가 아니라, 그걸 안 놓는 subscribers 리스트 예요. 객체가 나쁜 게 아니라, 다 쓴 객체를 놓아주지 않는 그 손이 문제인 거죠. 그러니 해결책도 거기서 나와요. 리스트가 손을 놓게 만들면 돼요.

Step 7: 누수 해결하기 — 손을 놓게 만들기

원인을 알았으니 고치는 건 의외로 간단해요. 리스트가 다 쓴 구독자를 놓도록, 등록할 때마다 짝이 되는 해지를 붙여주면 돼요. 같은 데모 안에 누수가 없는 버전도 준비해 뒀어요.

// com/instagram/javabasic/jvm/MemoryLeakDemo.java

// 등록과 해지를 1:1 로 짝지어 누수를 막는 버전이에요.
public static SubscriptionRegistry leakFreeWithUnsubscribe(int rounds) {
    SubscriptionRegistry registry = new SubscriptionRegistry();
    for (int i = 0; i < rounds; i++) {
        NamedSubscriber subscriber = new NamedSubscriber("subscriber-" + i);
        // 등록한 그 객체를 그대로 해지해요. 이 짝맞춤이 누수를 막는 안전선이에요.
        registry.subscribe(subscriber);
        registry.unsubscribe(subscriber);
    }
    return registry;
}

subscribe() 바로 다음에 unsubscribe() 가 짝으로 붙었죠. 구독자가 등록부에 들어갔다가 곧바로 빠지니, 리스트엔 아무도 안 남아요. 이 메서드는 rounds 가 아무리 커도 끝나고 나면 등록부 크기가 0 이에요. 다 쓴 구독자를 붙드는 손이 없으니, 가비지 컬렉터가 바로바로 치울 수 있어요.

실제 화면 처리에선 구독을 더 늦게 정리하기도 해요. Day 43 과제에서 만든 EventSubscriptionManager 처럼, 화면이 닫히는 순간 한 번에 전체를 비우는 방법이죠.

// com/instagram/javabasic/jvm/solution/day43/EventSubscriptionManager.java

// 화면이 닫힐 때 전체 구독을 한 번에 정리해요. 누수를 막는 안전선이에요.
public void unsubscribeAll() {
    subscribers.clear();
}

clear() 로 리스트를 통째로 비우면, 구독자들을 붙들던 마지막 강한 참조가 한 번에 끊겨요. 그 순간 구독자 전부가 가비지 컬렉터의 청소 대상이 되죠.

고치고 나서 다시 보면

이렇게 짝이 되는 해지를 붙인 뒤 같은 진단을 다시 해봤어요. VisualVM 그래프는 계단식 상승이 사라지고 다시 톱니 모양 으로 돌아왔어요. 쌓였다가 GC 때 뚝 떨어지고, 다시 쌓였다 떨어지고. 그리고 Heap 덤프를 다시 떠보니 NamedSubscriber 개수가 0 에 가깝게 떨어져 있었어요.

[Before] 누수 — 치워도 안 내려가고 계속 우상향
힙 │        ___
   │     ___
   │  ___
   └─────────────  시간

[After] 해결 — 톱니 모양으로 복귀
힙 │   /|  /|  /|
   │  / | / | / |
   │ /  |/  |/  |__
   └────────────────  시간

Day 41 에서 Observer 를 배울 때 "구독했으면 필요 없어질 때 해지하는 습관이 중요하다" 고 했던 그 한마디가, 메모리 누수를 막는 진짜 안전선이었던 거예요. 그리고 지난 시간 잠깐 봤던 WeakReference(약한 참조) 를 떠올려보세요. 깜빡 잊고 해지를 못 할까 봐 걱정된다면, 처음부터 약하게 붙들어서 가비지 컬렉터가 알아서 치우게 두는 선택지도 있어요. 해지를 짝지어 주거나, 약하게 붙들거나 — 둘 다 "다 쓴 객체를 놓아준다" 는 같은 목표를 향해요.

💡 오늘 기억할 한 줄: 누수의 해결은 결국 "붙들던 손을 놓는 것" 이에요. 등록엔 해지를 짝지어 주고, 화면이 닫히면 한 번에 비워주세요.

Step 8: 튜닝 전략 — 언제 무엇을 꺼내 쓸까

오늘 손잡이를 여러 개 만져봤어요. 마지막으로, 이걸 실무에서 언제 어떻게 꺼내 쓰는지 를 정리해 볼게요. 도구는 많이 아는 것보다 "이 상황엔 이걸" 하고 고를 줄 아는 게 중요하거든요.

환경에 따라 다르게

• 개발 환경 (내 PC) — 평소 개발할 땐 기본값으로 충분해요. 옵션을 굳이 안 줘도 JVM 이 알아서 잘 잡아줘요. 누수가 의심될 때만 VisualVM 을 띄워 그래프를 살펴보면 돼요.
• 테스트 / CI 환경 — 메모리가 제한된 곳에서 돌 때가 많아요. GC 로그(-Xlog:gc*)를 켜두면, 나중에 "여기서 메모리가 빡빡했구나" 를 일지로 되짚어 볼 수 있어요.
• 프로덕션 (실제 서버) — 힙 크기를 명확히 정하고(-Xms 와 -Xmx 를 같게), GC 로그를 파일로 남겨 꾸준히 지켜봐요. 눈으로 계속 못 보는 환경이라, 기록과 경보가 생명이에요.

누수가 의심될 때, 진단 순서

오늘 배운 도구들을 실제로 쓸 땐 이런 순서로 가면 돼요.

1. GC 로그를 켠다 (-Xlog:gc*)
       ↓  화살표 뒤 숫자가 안 줄어드나?
2. VisualVM 으로 그래프를 본다
       ↓  톱니인가, 우상향 계단인가?
3. 계단이면 Heap 덤프를 뜬다
       ↓  비정상적으로 많은 클래스는?
4. 그 객체의 참조 그래프를 본다
       ↓  누가 안 놓고 붙들고 있나?
5. 그 손을 놓게 고친다 (해지 / 약한 참조)

이 다섯 단계가 오늘 우리가 Step 2 부터 7 까지 한 바퀴 돌아본 그 흐름이에요. 막막하던 "메모리가 새는 것 같아요" 가, 이제는 차근차근 따라가서 범인을 잡는 절차로 바뀐 거죠.

🌟 추천 첫걸음: 누수가 의심되면 무조건 덤프부터 뜨지 말고, GC 로그 → VisualVM 그래프 로 "정말 새는지" 부터 확인하세요. 멀쩡한데 괜히 덤프 떠서 분석하느라 시간 버리는 일이 흔하거든요.

마무리

오늘은 지난 시간 그림으로만 그렸던 메모리 이야기를, 도구를 들고 직접 진단해 본 실전이었어요. 정비사가 보닛을 열고 계기판을 들여다본 하루였죠.

• JVM 메모리 옵션 — -Xmx(최대)·-Xms(시작)·-Xmn(young)으로 힙 크기를 직접 정했어요. 너무 작으면 OOM, 너무 크면 낭비예요.
• GC 로그 — -Xlog:gc* 로 가비지 컬렉터의 일지를 켜고, 116M->34M(256M) 한 줄을 "청소 전 → 후 (전체)" 로 읽었어요.
• VisualVM — 실행 중인 프로그램의 Heap 을 실시간 그래프로 봤어요. 톱니면 건강, 우상향 계단이면 누수.
• 누수 재현 — Day 43 의 SubscriptionRegistry 를 실제로 돌려, 청소해도 안 줄어드는 메모리를 눈으로 잡았어요.
• Heap 덤프와 참조 그래프 — 그 순간 메모리를 사진 찍어 범인 클래스를 찾고, 누가 그걸 붙들고 있는지 사슬을 따라갔어요.
• 해결과 전략 — 짝이 되는 해지로 손을 놓게 만들고, 환경별로 어떤 도구를 꺼낼지 정리했어요.

이제 "메모리가 새는 것 같아요" 라는 막연한 불안이, 차근차근 따라가 범인을 잡아내는 다섯 단계 절차로 바뀌었어요. 이게 오늘의 가장 큰 수확이에요.

그런데 한 가지 묘한 게 남아요. VisualVM 은 우리 프로그램 속을 들여다보면서 NamedSubscriber 라는 클래스 이름 을 어떻게 다 알아냈을까요? 그리고 지난 시간 배운 Metaspace 에 담긴 그 클래스 정보는, 대체 누가 읽어서 올려놓는 걸까요? 다음 시간엔 클래스를 메모리에 실어 나르는 클래스 로더, 실행 중에 클래스 속을 들여다보는 리플렉션(reflection), 그리고 @ 로 시작하는 어노테이션 의 정체를 파헤쳐 봅니다. 오늘 덤프에서 본 클래스 이름들이, 그때 또 다른 의미로 살아날 거예요. 수고 많으셨어요!

과제

오늘은 도구를 직접 손에 익히는 게 핵심이었어요. 과제도 눈으로 보고 손으로 만져보는 쪽으로 준비했어요.

과제 1: 힙을 좁혀 OutOfMemoryError 만나보기 [기초]

IntelliJ 의 Run Configuration VM options 칸에 힙을 아주 작게 주고(-Xmx16m 처럼), 동시에 GC 로그(-Xlog:gc)를 켜서 아무 프로그램이나 실행해 보세요. 콘솔에 GC 로그가 어떻게 찍히는지 관찰하고, 한 줄을 골라 "청소 전 → 후 (전체)" 로 해석해 보세요. 힙을 더 좁히면 어떤 에러가 나는지도 확인해 보세요.

과제 2: 누수를 재현하고 덤프로 진단하기 [응용]

MemoryLeakDemo 의 main 을 실행하고 VisualVM 으로 Heap 그래프를 지켜보세요. 그래프가 톱니인지 계단인지 적어보고, Heap 덤프를 떠서 어떤 클래스의 인스턴스가 비정상적으로 많은지 찾아보세요. 그다음 leakWithoutUnsubscribe 와 leakFreeWithUnsubscribe 가 끝난 뒤 등록부 크기가 각각 어떻게 다른지, 그 차이가 왜 생기는지 설명해 보세요.

과제 3: 나만의 누수 시나리오 설계하기 [심화]

구독 등록부 말고, 누수가 날 수 있는 다른 상황을 하나 직접 떠올려 설계해 보세요. (힌트: 캐시처럼 Map 에 데이터를 계속 넣기만 하고 안 빼면 어떻게 될까요?) 어떤 자료구조가 무엇을 강하게 붙들어서 누수가 나는지 글로 분석하고, 이를 막는 두 가지 방법 — 다 쓰면 빼주기 vs 약한 참조로 붙들기 — 를 비교해 보세요. 각 방법이 어떤 상황에 더 어울릴지도 함께요.

생각해볼 주제

1. 가비지 컬렉터가 자동인데, 자바에 왜 메모리 누수가 있을까

자바는 C/C++ 와 달리 메모리를 자동으로 치워주는데도 메모리 누수가 생겨요. "자동" 이라는 말과 "누수" 라는 말이 같이 있는 게 모순처럼 느껴지죠. 가비지 컬렉터가 객체를 치우는 기준이 무엇이었는지 떠올리면서, 자동 청소가 막아주는 것과 막아주지 못하는 것의 경계를 생각해 보세요.

2. 힙은 크게 줄수록 좋은 걸까

OutOfMemoryError 가 무서우니 -Xmx 를 무조건 크게 주면 안전할 것 같아요. 하지만 큰 힙에는 보이지 않는 비용도 따라와요. 가비지 컬렉터가 한 번 청소할 때 훑어야 할 양과, 그동안 프로그램이 멈추는 시간을 떠올리면서, 힙 크기를 키울 때의 득과 실을 저울질해 보세요.

3. 누수가 무서우면 전부 약한 참조로 만들면 되지 않을까

해지를 깜빡해도 약한 참조면 가비지 컬렉터가 알아서 치워주니, 모든 걸 WeakReference 로 들고 있으면 누수 걱정이 없을 것 같아요. 정말 그럴까요? 약한 참조로 들고 있던 객체가 "내가 아직 쓰고 싶은데" 갑자기 사라진다면 어떤 일이 벌어질지, 약한 참조가 잘 어울리는 경우와 그렇지 않은 경우를 나눠 생각해 보세요.