ITEM 8: Avoid finalizer and cleaner

자바는 finalizer, cleaner두 가지 객체 소멸자를 제공한다. finalizer와 cleaner는 GC가 더 이상 사용하지 않는 자원에 대한 정리작업을 진행하기 위해 사용된다.

finalizer

• 예측이 불가능하며, 상황에 따라 위험할 수 있어 일반적으로 불필요

• 오동작, 낮은 성능, 이식성 문제의 원인

finalizer 나름의 쓰임새가 있지만 기본적으로 사용을 지양해야한다. (Java 9에서 deprecated)

cleaner

cleaner는 finalizer의 대안으로 소개되었다. cleaner는 finalizer보다는 덜 위험하지만 여전히 아래 단점을 가지고 있다.

• 예측 불가능

• 느림

• 일반적으로 불필요

사용을 지양해야하는 이유

1. finalizer와 cleaner로는 제때 실행되어야 하는 작업은 절대 알 수 없다.

finalizer와 cleaner는 즉시 수행된다는 보장이 없으며, 객체에 접근할 수 없게 된 후 finalizer와 cleaner가 실행될 때까지 어느정도 걸리는지 알 수 없다. 예를 들어, 파일 닫기를 finalizer/ cleaner에 맡기게 된다면 시스템이 동시에 열 수 있는 파일 개수에 한계가 있기에 오류가 발생할 수 있다. 클래스에 finalizer를 달아두면 인스턴스의 자원 회수가 제멋대로 지연될 수 있다. 실제로 원인을 알 수 없는 OutOfMemoryError가 발생해 분석해보았을 때, 애플리케이션이 죽는 시점에 객체 수천개의 finalizer 스레드는 다른 애플리케이션 스레드 보다 우선순위가 낮아 대기열에서 회수되기만을 기다리고 있었다. cleaner는 자신이 수행할 스레드를 제어할 수 있다는 점에서 낫지만, 여전히 백그라운드에서 수행되며 가비지 컬렉터의 통제하에 있어 즉각 수행된다는 보장이 없다. 또한, 자바는 finalizer와 cleaner의 수행 시점 뿐만 아니라 수행 여부 조차 보장하지 않는다. 이것은 접근할 수 없는 일부 객체에 종료 작업을 전혀 수행하지 못한 채 프로그램이 중단 될 수도 있다는 것이다.

즉, 상태를 영구적으로 수정하는 작업에서 절대 finalizer와 cleaner에 의존하면 안된다.

System.gc, System.runFinalization 은 finalizer와 cleaner가 실행될 가능성은 높여줄 수 있으나, 보장해주지 않으며, System.runFinalizersOnExit과 Runtime.runFinalizersOnExit은 실행을 보장해준다고 되어있지만 ThreadStop 의 심각한 결함 문제가 있다.

또한, finalizer는 동작 중 발생한 예외는 무시되며, 처리할 작업이 남아 있더라도 그 순간 종료된다. 잡지 못한 예외 때문에 해당 객체는 마무리가 덜 된 상태로 남아 있을 수 있으며, 다른 스레드가 훼손된 객체를 사용하려 한다면, 어떻게 동작할지 예측할 수 없다. (cleaner는 자신의 스레드를 통제하므로 이러한 문제 발생안함)

2. finalizer와 cleaner는 심각한 성능 문제도 동반될 수 있다.

AutoCloseable 객체를 생성해 GC가 수거하기 까지 12ns가 걸린 것이, finalizer를 사용하니 550ns가 걸렸다. finalizer가 GC의 효율을 떨어뜨리기 때문이다.

cleaner도 클래스의 모든 인스턴스를 수거하는 형태로 사용하면 finalizer와 성능은 유사하며, 안정망 방식을 사용하면 약 66ns가 걸리나, 안전망을 설치하면 성능이 약 5배 정도 느려진다.

3. finalizer를 사용한 클래스는 finalizer 공격에 노출되어 심각한 보안 문제를 일으킬 수 있다.

생성자나 직렬화 과정에서 예외가 발생하면, 생성되다 만 객체에서 악의적으로 하위 클래스의 finalizer가 수행될 수 있다. 이 finalizer는 정적 필드에 자신의 참조를 할당해 GC가 수집하지 못하게 막을 수 있다.

객체 생성을 막기위해 생성자에서 예외를 던질 수 있지만, finalizer가 있다면 이도 불가능하다.

final이 아닌 클래스를 finalizer 공격으로 방어하려면 아무 로직이 없는 finalize 메서드를 만든 후 final로 선언하면 된다.

사용하는 곳

1. 자원의 소유자가 close 메서드를 호출하지 않는 것에 대비한 안정망 역할로 사용 (언제 회수 될지 모르지만 늦게라도 해주는 것이 좋음 ) - FileInputStream, FileOutputStream, ThreadPoolExecutor에서 안전망 역할의 finalizer 제공

2. *Native Peer는 자바 객체가 아니므로 GC가 그 존재를 알지 못한다. 즉, 네이티브 피어와 연결된 객체에서의 자원 회수용으로 사용한다. 단, 성능 저하를 감당할 수 있고 네이티브 피어가 심각한 자원을 가지고 있지 않을 때만 해당한다. 성능저하를 감당할 수 없거나 자원을 즉시 회수해야한다면 close 메서드를 사용해야한다.

cleaner는 안전망 역할이나 중요하지 않은 네이티브 자원 회수 용으로만 사용하며, 이 경우에도 불확실성과 성능저하에 유의해야한다.

\ Native Peer : 일반 자바 객체가 네이티브 메서드를 통해 기능을 위임한 네이티브 객체*

대안

파일이나 스레드 등 종료해야 할 자원을 담고 있는 객체의 클래스에서 finalizer와 cleaner를 대신해주려면 AutoCloseable을 구현해주고, close 메서들르 호출하면된다.(try-with-resources(item 9))

각 인스턴스는 close 메서드에서 더 이상 유효하지 않음을 기록하고, 다른 메서드는 해당 필드를 검사해 객체가 닫힌 후에 호출했다면 IllegalStateException 오류를 발생시키는 것이다.

참고

• yundeleyundle.log - [Item8] finalizer와 cleaner사용을 피하라