item08: finalizer와 cleaner 사용을 피하라

[joona95]

💡 주제

item08: finalizer와 cleaner 사용을 피하라

📌 TO DO

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

[joona95]

finalizer와 cleaner는 즉시 수행된다는 보장이 없다.

Q. 구현이 어떻게 돼있길래 즉시 수행되지 않는가?

• finalizer나 Cceaner는 GC와 별도의 비동기 큐 기반으로 작동하기 때문에, “언제 실행될지 JVM이 보장하지 않는다.”

finalizer

• 자바에서 객체가 더 이상 참조되지 않으면, GC가 즉시 메모리를 해제하는 게 아니라, 먼저 “이 객체에 finalize()가 정의돼 있나?”를 확인
• 있으면 그 객체를 “finalizer queue” 로 보냄
• 바로 지우지 않고, 백그라운드 스레드가 따로 그 큐를 순회하면서 finalize()를 실행함
• GC 타이밍 + 스레드 스케줄링, 두 가지가 모두 변수이기 때문에 “즉시 실행된다”는 보장이 없음

cleaner

• Java 9부터 **Cleaner (java.lang.ref.Cleaner)**가 추가됐는데, 이건 내부적으로 PhantomReference + 백그라운드 스레드로 구현
• GC가 객체를 회수하기 직전에 ReferenceQueue에 PhantomReference를 넣음
• 백그라운드 스레드(CleanerThread)가 그 큐를 polling 후 Runnable을 실행
• 그 이후 객체가 메모리에서 실제 해제됨

---

한편, cleaner는 자신을 수행할 스레드를 제어할 수 있다는 면에서 조금 낫다

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

• finalizer는 JVM이 내부적으로 관리하는 단 하나의 고정된 FinalizerThread에서만 동작 (개발자는 이 스레드를 만지거나 바꿀 수 없음)

• Cleaner는 개발자가 직접 제어 가능한 스레드에서 작동시킬 수 있음 (즉, “누가 언제 어떤 방식으로 정리 작업을 수행할지”를 어느 정도 컨트롤 가능)

  • CleanerThread 는 데몬(daemon) 스레드로 동작하며, 필요하다면 개발자가 커스텀 스레드 팩토리(ThreadFactory) 를 통해 cleaner 스레드를 직접 제어 가능

  Executor executor = Executors.newSingleThreadExecutor(r -> {
      Thread t = new Thread(r, "MyCleanerThread");
      t.setPriority(Thread.MIN_PRIORITY);
      return t;
  });
  Cleaner cleaner = Cleaner.create(executor);

---

System.gc나 System.runFinalization 메서드에 현혹되지 말자. finalizer와 cleaner가 실행될 가능성을 높여줄 수는 있으나, 보장해주진 않는다.

Q. 무슨 의미인지?

• System.gc()나 System.runFinalization()은 GC와 finalizer를 "요청"할 뿐, 강제가 아니라서 실행을 보장하지 않는다.
  • System.gc() → JVM에게 “지금 한 번 GC 돌려주세요~”라는 권고
  • System.runFinalization() → “finalize()를 한 번 실행해보세요~”라는 요청

---

사실 이를 보장해주겠다는 메서드가 2개 있었다. 바로 System.runFinalizersOnExit와 그 쌍둥이인 Runtime.runFinalizersOnExit다. 하지만 이 두 메서드는 심각한 결함 때문에 수십 년간 지탄받아 왔다.

Q. 어떻게 보장해주겠다는 건지? 어떤 결함이 있는지?

• JVM 종료 시 모든 객체의 finalize()를 강제로 호출하려다가, 심각한 스레드 안전성 문제 / 보안 취약점 / 부활(resurrection) 문제를 유발

• Java 1.2 이후로 공식적으로 deprecated, “절대 사용 금지”로 분류

1) 스레드 안전성(Thread Safety) 붕괴

finalizer가 JVM 종료 도중에 강제로 실행되면,

• 이미 일부 클래스 로더나 모듈이 unload 중일 수 있고,

• 일부 스레드는 이미 종료되었을 수도 있으며,

• 락(lock) 상태가 불안정합니다.

결과적으로:

• 락 순서가 꼬여서 교착상태(Deadlock) 발생

• finalize 내부에서 다른 객체 접근 → NullPointerException

• 객체 상태 불안정 → 데이터 손상, 로그 누락

즉, 종료 직전 JVM은 thread-safe하지 않다는 근본적인 이유로 이게 매우 위험합니다.

2) 객체 부활(resurrection) 가능성

finalize() 메서드 안에서 흔히 객체를 되살리는 실수를 할 수 있습니다.

그런데 runFinalizersOnExit()은 프로그램 종료 직전에 모든 finalize를 강제로 돌리기 때문에, 이미 종료 중인 프로그램이 갑자기 “부활한 객체”를 들고 있게 되는 완전히 정의되지 않은 상태(undefined state)에 빠집니다.

즉, 프로그램이 끝났는데 객체가 살아 있어서 논리적 일관성이 깨집니다.

3) 보안(Security) 취약점

JVM 종료 중에 실행되는 finalize()는 보안 검증이 무력화된 상태에서 실행됩니다.

예를 들어, SecurityManager가 이미 해제되었거나, 클래스 로더가 unload 중이라 권한 체크가 우회됨.

그 결과, finalize() 안에서 악의적인 코드(파일 삭제, 네트워크 전송 등)를 실행하면 보안 sandbox를 뚫을 수 있는 취약점이 있었습니다.

실제로 이 문제가 발견되어 JDK 1.1~1.2 시절에 “심각한 보안 결함”으로 보고된 적이 있다고 합니다.

4) 예측 불가능한 실행 순서 / 중복 실행

JVM이 종료 중일 때는 객체 생성 순서나 finalize 호출 순서가 보장되지 않습니다.

게다가 어떤 객체의 finalize가 또 다른 객체의 finalize를 다시 호출할 수도 있어요.

결과적으로:

• finalize()가 중복 호출될 수 있음.

• finalize 실행 중 JVM이 이미 종료 완료되어, 파일 핸들이 닫혀 있을 수도 있음.

• 결과는 예측 불가능.

---

finalizer 동작 중 발생한 예외는 무시되며, 처리할 작업이 남았더라도 그 순간 종료된다.

Q. 왜 그렇게 동작하는지?

• finalize()는 프로그램의 주 실행 흐름과 무관한, 비동기적인 정리 코드(cleanup code) 이기 때문에 예외가 밖으로 전파되면 JVM 전체 안정성을 해칠 수 있어서, JVM이 강제로 삼켜(무시) 버리는 구조로 되어 있습니다.

// (단순화된 OpenJDK Finalizer 스레드 구조)
public void run() {
    for (;;) {
        Finalizer f = (Finalizer) queue.remove();
        try {
            f.runFinalizer(); // 여기서 객체의 finalize() 호출
        } catch (Throwable t) {
            // ⚠️ 예외 무시
        }
    }
}

• 스레드는 전역적으로 하나뿐이고, JVM 내부적으로 다음과 같은 루프 돌면서 try { ... } catch (Throwable)로 감싸고 아무 처리도 하지 않습니다
• finalizer는 JVM 내부 백그라운드 스레드에서 실행됩니다. 만약 여기서 던진 예외가 상위로 전파되면, FinalizerThread 자체가 종료될 수 있음.
  • 그럼 이후 finalize가 필요한 다른 객체들이 모두 실행되지 못하고 누락됩니다.
  • 한 객체의 finalize() 실패가 다른 객체의 정리까지 망치면 안 되기 때문에 예외 전파가 되지 않도록 설계되었습니다.
• 객체의 생명주기상 마지막 시점에서 발생한 예외는 의미 있는 복구가 불가능합니다
• finalizer는 개발자가 직접 try/catch로 감쌀 수 있는 코드가 아닙니다. GC가 내부적으로 실행하니까, 예외가 발생하면 이를 “누가 처리할지” 명확하지 않습니다.

---

정적이 아닌 중첩 클래스는 자동으로 바깥 객체의 참조를 갖게 되기 때문이다

Q. 정확히 무슨 의미?

• 비정적 내부 클래스는 바깥 클래스의 인스턴스 멤버에 접근할 수 있도록 컴파일러가 자동으로 바깥 객체 참조 필드(Outer.this)를 삽입하기 때문에,
  바깥 객체를 암묵적으로 붙잡게 된다.

• 반대로, 정적 중첩 클래스(static)는 이런 참조가 없어 바깥 객체와 독립적으로 동작하고 메모리 누수 위험도 없다.

• 참고 : 내부 클래스는 static 으로 선언 안하면 큰일 난다
  출처: https://inpa.tistory.com/entry/JAVA-☕-자바의-내부-클래스는-static-으로-선언하자 [Inpa Dev 👨‍💻:티스토리]

---

이와 비슷하게 람다 역시 바깥 객체의 참조를 갖기 쉬우니 사용하지 않는 것이 좋다.

Q. 정확히 무슨 의미?

• 람다도 비정적 내부 클래스처럼 바깥 상태를 은근히 잡고 있어서 메모리 누수의 원인이 될 수 있다는 뜻
  • static 문맥(정적 메서드 등) 에서 쓰면 안전
  • 인스턴스 문맥에서 바깥 상태를 캡처하면 메모리 누수 위험