메모리 누수와 트러블슈팅 — OOM이 발생하면 어떻게 하나요

GC Root → A → B → C   ← 전부 reachable, 회수 안 됨
GC Root → A → B        ← C는 unreachable, 회수됨

public class CacheManager {
    // static이니까 클래스가 언로드되지 않는 한 영원히 살아있음
    private static final Map<String, byte[]> cache = new HashMap<>();

    public static void put(String key, byte[] data) {
        cache.put(key, data);
    }
    // remove()를 호출하지 않으면? → 계속 쌓인다
}

public class EventBus {
    private final List<EventListener> listeners = new ArrayList<>();

    public void register(EventListener listener) {
        listeners.add(listener);
    }
    // unregister()를 깜빡하면?
    // → listener가 참조하는 모든 객체가 GC되지 않음
}

public class UserContext {
    private static final ThreadLocal<UserSession> currentSession = new ThreadLocal<>();

    public static void set(UserSession session) { currentSession.set(session); }
    public static UserSession get() { return currentSession.get(); }
    // 요청이 끝나면 반드시 remove()!
    public static void clear() { currentSession.remove(); }
}

public class Outer {
    private byte[] bigData = new byte[10 * 1024 * 1024]; // 10MB

    // 비정적 내부 클래스 → Outer에 대한 암묵적 참조를 가짐
    public class Inner {
        public void doSomething() {
            // bigData를 직접 안 써도, Outer 참조는 유지됨
        }
    }
}
// Inner 객체가 살아있는 한 Outer(10MB)도 GC되지 않음
Outer.Inner inner = new Outer().createInner();

Object obj = new Object();
WeakReference<Object> weakRef = new WeakReference<>(obj);
obj = null; // Strong Reference 제거
// 다음 GC에서 weakRef.get()은 null을 반환

byte[] bigData = new byte[10 * 1024 * 1024]; // 10MB
SoftReference<byte[]> softRef = new SoftReference<>(bigData);
bigData = null;
// 메모리가 충분하면 유지, 부족하면 GC가 수거

ReferenceQueue<Object> queue = new ReferenceQueue<>();
Object obj = new Object();
PhantomReference<Object> phantomRef = new PhantomReference<>(obj, queue);
obj = null;
// phantomRef.get()은 항상 null
// GC가 객체를 수거하면 phantomRef가 큐에 등록됨 → 정리(cleanup) 용도

# OOM 발생 시 자동으로 힙 덤프 생성 — 운영 환경 필수!
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/log/heapdump/ \
     -Xmx512m -jar myapp.jar

# 실행 중인 JVM의 PID 확인 후 덤프
jps -l
jcmd <PID> GC.heap_dump /tmp/heapdump.hprof

A (100 bytes) → B (200 bytes) → C (300 bytes)
                → D (150 bytes)

[분석 흐름 예시]
Dominator Tree에서 가장 큰 객체:
  com.myapp.service.CacheManager → Retained: 800MB

Path to GC Roots:
  Thread "main"
    → static CacheManager.cache → HashMap → HashMap$Node[] (100만 개)

결론: static HashMap에 데이터가 계속 쌓여서 누수 발생

# 스레드 덤프 생성
jcmd <PID> Thread.print > threaddump.txt
# 또는
jstack <PID> > threaddump.txt

"http-nio-8080-exec-1" #25 daemon prio=5
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at com.myapp.service.SlowService.process(SlowService.java:42)

[정상] 톱니 모양 — GC가 주기적으로 회수
     ╱╲  ╱╲  ╱╲  ╱╲
    ╱  ╲╱  ╲╱  ╲╱  ╲

[누수] 우상향 — GC 후에도 기저 메모리가 계속 증가
           ╱╲  ╱╲ ╱╲
        ╱╲╱  ╲╱  ╲
     ╱╲╱
    ╱

# JFR 시작
jcmd <PID> JFR.start duration=60s filename=/tmp/recording.jfr

# JVM 옵션으로 시작 시부터 기록
java -XX:StartFlightRecording=duration=300s,filename=app.jfr -jar myapp.jar

jstat -gcutil <PID> 1000 10  # 1초 간격으로 10회 GC 통계 출력

  S0     S1     E      O      M     CCS    YGC   YGCT   FGC   FGCT    GCT
  0.00  99.12  87.45  98.34  95.67  92.34   523  12.45    47   38.92  51.37

jcmd <PID> GC.heap_dump /tmp/heapdump.hprof

// Before: 누수 — 세션을 넣기만 하고 제거하지 않음
private static final Map<String, UserSession> sessions = new ConcurrentHashMap<>();

// After: 만료 정책이 있는 캐시 사용
private static final Cache<String, UserSession> sessions = Caffeine.newBuilder()
        .expireAfterAccess(30, TimeUnit.MINUTES) // 30분 미접근 시 자동 제거
        .maximumSize(10_000)                      // 최대 1만 개
        .build();

# JFR로 30분간 기록하며 Old Gen 사용률이 안정적으로 유지되는지 확인
jcmd <PID> JFR.start duration=1800s filename=/tmp/after-fix.jfr
jstat -gcutil <PID> 5000