item07: 다 쓴 객체 참조를 해제하라

[joona95]

💡 주제

item07: 다 쓴 객체 참조를 해제하라

📌 TO DO

• 발표 내용 작성
• 질문 작성

[leevigong]

추가)

• WeakReference 언제 사용하는지 찾아보기
• 다 쓴 객체를 직접 해제하는 경험을 해본적이 있는지..?

[kdmstj]

WeakReference 사용하는 예시

스프링 웹 백엔드 개발시 WeakReference 를 직접 사용하는 사례는 별로 없는 것 같고 안드로이드 앱 개발시에 많이 사용되는 것 같습니다.

1. 캐시 구현

• 메모리 절약이 필요한 캐시에 WeakReference를 활용
• 외부에서 참조가 사라지면 GC가 캐시 항목을 자동으로 제거.

Map<Key, WeakReference<Value>> cache = new ConcurrentHashMap<>();

2. 콜백 / 리스너

• 수명주기가 불확실한 객체(예: View, Activity, Listener)를 약하게 참조하여 메모리 누수 방지

class SafeCallback {
    private final WeakReference<Listener> listenerRef;
}

Spring 에서 WeakReference 사용 예시

다만, Spring Framework 내에서도 WeakReference 를 사용하고 있었습니다. 참고로 알아두면 좋을 것 같습니다.
Spring 내부에서는 리플렉션, 애노테이션, 타입 메타데이터 같은 다시 생성 가능한 임시 캐시를 WeakReference로 관리합니다.

주요 사용처

• CachedIntrospectionResults: Bean 클래스의 리플렉션 결과 캐시
• AnnotationMetadata: 애노테이션 분석 결과 캐시
• ResolvableType: 제네릭 타입 분석 캐시
• ConcurrentReferenceHashMap: Weak/Soft 참조 기반 Map 구현체

[HyunJng]

8장에서 GC 동작의 불확실성 때문에 finalizer과 cleaner이 deprecated되었는데, WeakReference는 아니라고 하니 둘에 무슨 차이가 있었는지 알아봤는데요.
둘의 차이는 반드시 실행이 되어야하는 것과 하면 좋은데 안되도 문제가 발생하지 않는 것 이더라고요.

• WeakReference는 GC 타이밍에 의존하더라도 부작용이 없는 패턴.
  • 단지 “GC가 객체를 더 이상 필요 없다고 판단하면 사라진다”라는 사실을 반영할 뿐.
  • 따라서 캐시나 리스너 같은 “있으면 좋고 없어도 괜찮은” 데이터를 관리할 때 안전하게 사용 가능.
• 반면 finalizer나 Cleaner는 GC의 타이밍에 필수 행동을 맡기는 것이므로
  • 시스템 자원 누수나 타이밍 문제를 초래하기 때문에 금지.

[joona95]

상대적으로 드문 경우긴 하지만 심할 때는 디스크 페이징이나 OutOfMemoryError를 일으켜 프로그램이 예기치 않게 종료되기도 한다.

디스크 페이징

• 운영체제 수준에서 메모리가 부족할 때 발생하는 비상조치입니다.
• 운영체제는 프로그램이 사용하는 가상 메모리(Virtual Memory) 를 제공합니다. 실제 물리 RAM이 부족해도, OS는 일부 메모리 페이지(데이터 덩어리) 를 디스크(보조기억장치) 로 옮겨놓고 필요할 때 다시 불러옵니다.
  • 이걸 “스와핑(Swapping)” 또는 “페이징(Paging)” 이라고 합니다.
  • 이때 디스크에 만들어지는 공간이 스왑 영역(Swap Space) 또는 페이지 파일(page file) 입니다.
• RAM은 나노초(ns) 단위로 접근하지만, 디스크(특히 HDD)는 밀리초(ms) 단위로 접근합니다. 그래서 메모리가 부족해 OS가 디스크로 스와핑을 하기 시작하면, 프로그램이 미친 듯이 느려집니다.
• 즉, OutOfMemoryError까지는 안 갔지만, RAM이 꽉 차서 디스크에 메모리 일부를 내보내는 상태를 의미합니다.

OutOfMemoryError

• java.lang.OutOfMemoryError = JVM이 사용할 수 있는 힙 공간(Heap Space) 이 부족할 때 던지는 오류
• 힙 크기 한도(-Xmx)를 넘어서 객체를 더 만들면 → OOME

---

자바의 참조

Strong Reference

Object obj = new Object();

• 자바의 모든 참조는 기본적으로 강한 참조(strong reference)
• GC는 절대 이 객체를 회수하지 않음.
• obj가 스코프 안에 있는 한 메모리에 반드시 남아 있음

Soft Reference

Object data = new Object();
SoftReference<Object> ref = new SoftReference<>(data);
data = null; // 강한 참조 제거

• GC가 즉시 회수하지 않고, 메모리가 부족해질 때 회수
• 캐시(Cache) 용도로 자주 쓰임
• 메모리가 여유 있으면 오래 유지되고, 부족해지면 제거되어 자동 정리.
• 이미지 캐시, DB 연결 캐시 등 “다시 만들어도 큰 손해는 없는” 데이터에 적합.

Weak Reference

Object data = new Object();
WeakReference<Object> ref = new WeakReference<>(data);
data = null;
System.gc(); // 다음 GC 때 회수

• 다음 GC 사이클에서 바로 수거됨.
• 참조가 약해서, 강한 참조가 하나도 남지 않으면 곧바로 회수.
• WeakHashMap은 이 원리를 이용해서 키를 약한 참조로 관리
• 캐시, 리스너 목록, 메모리 민감 객체 관리

Phantom Reference

ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> ref = new PhantomReference<>(new Object(), queue);

• 객체가 finalize() 이후, GC 직전에 enqueue 됨
• 참조로 객체를 다시 접근할 수 없음 (get() → 항상 null).
• 주로 네이티브 리소스 추적, 객체 소멸 후 후처리(cleanup)용으로 사용
• 파일 핸들, 네이티브 메모리 해제, 자원 해제 시점 감지

---

다 쓴 참조를 해제하는 가장 좋은 방법은 그 참조를 담은 변수를 유효 범위(scope) 밖으로 밀어내는 것이다. 여러분이 변수의 범위를 최소가 되게 정의했다면(아이템57) 이 일은 자연스럽게 이뤄진다.

Q. 정확히 어떤 의미인지?

• 그 변수가 더 이상 접근할 수 없는 영역으로 나가서 자연스럽게 GC 대상이 되게 하라는 뜻

나쁜 예시

Object temp = null;
for (int i = 0; i < list.size(); i++) {
    temp = list.get(i);
    // ... temp 사용 ...
}
System.out.println(temp); // 여전히 참조 남음 ❌

• temp가 for문 바깥에 선언되어 있어서, 루프가 끝나도 마지막 객체를 계속 참조함 → GC가 회수 못함

좋은 예시

for (int i = 0; i < list.size(); i++) {
    Object temp = list.get(i);
    // ... temp 사용 ...
} // for문이 끝나면 temp의 스코프도 끝 → 참조 자동 해제 ✅

• temp의 유효 범위가 for문 내부로 제한되어, 루프가 끝나면 스택 프레임에서 사라짐 → GC가 객체 회수 가능.

---

캐시를 만들 때 보통은 캐시 엔트리의 유효 기간을 정확히 정의하기 어렵기 때문에 시간이 지날수록 엔트리의 가치를 떨어뜨리는 방식을 흔히 사용한다. 이런 방식에서는 쓰지 않는 엔트리를 이따금 청소해줘야 한다. (ScheduledThreadPoolExecutor 같은) 백그라운드 스레드를 활용하거나 캐시에 새 엔트리를 추가할 때 부수 작업으로 수행하는 방법이 있다. LinkedHashMap은 removeEldestEntry 메서드를 써서 후자의 방식으로 처리한다.

ScheduledThreadPoolExecutor 예시가 궁금

Map<String, CacheEntry> cache = new ConcurrentHashMap<>();

record CacheEntry(Object value, long createdAt) {}

ScheduledExecutorService executor = Executors.newSingleThreadScheduledExecutor();

executor.scheduleAtFixedRate(() -> {
    long now = System.currentTimeMillis();
    cache.entrySet().removeIf(e -> now - e.getValue().createdAt() > 10_000); // 10초 이상된 엔트리 삭제
}, 1, 1, TimeUnit.SECONDS);

• 백그라운드 스레드가 주기적으로 “쓰지 않는 엔트리”를 청소

LinkedHashMap.removeEldestEntry 어떻게 동작하는 건지? (OpenJDK 기준)

@Override
void afterNodeInsertion(boolean evict) { // put 후 호출
    LinkedHashMap.Entry<K,V> eldest;
    if (evict && (eldest = head) != null && removeEldestEntry(eldest)) {
        K key = eldest.key;
        removeNode(hash(key), key, null, false, true);
    }
}

• LinkedHashMap.removeEldestEntry()는 put() (또는 putAll()) 사용 시 내부에서 자동으로 호출됨
• put() 완료 후, afterNodeInsertion()이 자동 호출됨
• afterNodeInsertion() 호출 시 내부에서 removeEldestEntry(eldest)가 호출됨.