[이펙티브 자바] Item8. finalizer와 cleaner 사용을 피하라.

 

item08. finalizer와 cleaner 사용을 피하라. 

이펙티브 자바 part 1에서는 객체의 생성과 소멸에 대해서 얘기하고 있는데 지금은 저번 item 부터는 객체 소멸에 대해서 이야기 하고 있다. 

우선 자바에서는  두 가지 객체 소멸자를 제공한다.

finalizer와 cleaner인데 결론을 얘기하자면 둘다 사용을 권장하지 않는다. 아니 권장이 아니라 책에서는 사용하는 것을 피하라고 한다. (특히 finalizer)

 

특히 finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있기 때문에 일반적으로 불필요하다. 

그리고 오동작, 낮은 성능, 이식성 문제의 원인이 되기도 하기 때문에 기본적으론 쓰지 말라고 한다.

특히 java 9부터는 deprecated 되어서 대안으로 cleaner를 소개하고 있는데 cleaner는 그나마 finalizer보다는 덜 위험하지만, cleaner 역시 예측할 수 없고, 느리며 일반적으로 불필요하다. 

 

 

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

finalizer와 cleaner가 실행되기까지 얼마나 걸리는지 알 수 없기 때문에 제때 실행되어야 하는 작업에 절대 사용하면 안된다.

 

ex) 파일 닫기를 finalizer 혹은 cleaner에 맡기면 중대한 오류를 발생시킬 수 있다. 

-> 시스템이 동시에 열 수 있는 파일 개수에는 한계가 있는데 finalizer나 cleaner가 파일 닫기를 즉시 수행하지 않아서 파일을 계속 열어 둔다면 새로운 파일으 열지 못해서 프로그램이 실패하는 오류를 발생시킬 수 있다. 

 

 

 

2️⃣ finalizer나 cleaner 수행 시점뿐 아니라 수행 여부조차 보장하지 않는다. 

이 말은 즉 접근할 수 없는 일부 객체에 딸린 종료 작업을 전혀 수행하지 못한 채 프로그램이 중단될 수도 있다는 이야기이다. 

따라서 프로그램 생애 주기와 상관없는, 상태를 영구적으로 수정하는 작업에서는 절대 finalizer, cleaner 에 의존해서는 안된다. 

 

ex) 데이터베이스 같은 공유 자원의 영구 락(lock) 해제를 finalizer 또는 cleaner에 맡기면 분산 시스템 전체가 서서히 멈추게 될 것이다..

 

 

 

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

잡지 못한 예외 때문에 해당 객체는 마무리가 덜 된 상태로 남을 수도 있다. 

 

 

 

4️⃣ finalizer와 cleaner는 심각한 성능 문제도 동반한다. 

 

 

 

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

 

 

 

💡 대안

 

반납할 자원이 있는 클래스는 AutoCloseable 을 구현하고 클라이언트에서 close()를 호출하거나
try-with-resource를 사용해야 한다. 

 

 

AutoCloseable을 구현해주고, 클라이언트에서 인스턴스를 다 쓰고 나면 close 메서드를 호출하면 된다. 

(일반적으로는 예외가 발생해도 제대로 종료되도록 try-with-resource를 사용해야 한다.) 

그리고 cleaner는 안전망으로 사용해 하나의 자원의 소유자가 close메서드를 호출하지 않는 것에 대비한 안전망 역할을 하게 하면 된다. 

 

 

package chapter01.item08.cleaner_as_a_safetynet;

import java.lang.ref.Cleaner;

// cleaner를 안전망으로 활용하는 AutoClosable 클래스
public class Room implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create();

    // 청소가 필요한 자원, 절대 Room을 참조해서는 안된다!!
    private static class State implements Runnable {
        int numJunkPiles;

        State(int numJunkPiles) {
            this.numJunkPiles = numJunkPiles;
        }

        @Override
        public void run() {
            System.out.println("Cleaning room");
            numJunkPiles = 0;
        }
    }

    private final State state;

    private final Cleaner.Cleanable cleanable;

    public Room(int numJunkPiles) {
        state = new State(numJunkPiles);
        cleanable = cleaner.register(this, state);
    }


    @Override
    public void close()  {
        cleanable.clean();
    }
}

Room 클래스는 AutoCloseable을 구현하고, static으로 선언된 중첩 클래스인 State는 cleaner가 방을 청소할 때 수거할 자원들을 담고 있다. 

State 클래스는 Runnable을 구현하고 그 안의 run 메서드는 cleanable에 의해서 딱 한번만 호출될 것이다. 

이때 State 클래스는 절대 Room 인스턴스를 참조해서는 안된다!! 왜냐하면 Room 인스턴스를 참조할 경우 순환참조가 생기기 때문에 가비지  컬렉터가 Room 인스턴스를 회수해 갈 기회가 오지 않기 때문에 참조하면 안된다. 

 

cleanable 객체는 Room 생성자에서 cleaner에 Room과 State를 등록할 때 얻는다. 

 

그리고 run 메서드가 호출되는 상황은 둘 중 하나로 첫번째는 Room이 close 메서드를 호출할 때로 close 메서드에서 cleanable 의 clean 메서드를 호출하면 이 메서드 안에서 run 메서드를 호출한다. 

 

두번째로는 가비지 컬렉터가 Room을 회수할 때까지 클라이언트가 clean을 호출하지 않는다면 cleaner가 State의 run 메서드를 호출해줄 것이다. 

 

 

// cleaner 안전망을 갖춘 자원을 제대로 활용하지 못하는 클라이언트
public class Teenager {
    public static void main(String[] args) {
        new Room(99);
        System.out.println("Peace out");


        System.gc();
    }
}

첫번째 Teenager 클래스는 Cleaner 안전망을 갖춘 자원을 제대로 활용하지 못한 클라이언트로  clean을 호출하지 않았다가 System.gc() 추가로 인해 clenaer가 State의 run 메서드를 호출해서 "Cleaning room"이 출력되는 것을 확인할 수는 있을 것이다. 

 

// cleaner 안전망을 갖춘 자원을 제대로 활용하는 클라이언트
public class Adult {
    public static void main(String[] args) {
        try(Room myRoom = new Room(7)) {
            System.out.println("hi");
        }
    }
}

Audult 클래스는 cleaner 안전망을 갖춘 자원을 제대로 활용하는 클라이언트로 기대한 대로 "hi"와 "Cleaning room"이 출력되는 것을 확인할 수 있다. 

 

 

 

✏️ Room의 cleaner는 단지 안전망으로 클라이언트가 clean을 호출하지 않았을 때를 대비해서 만든 것으로 클라이언트가 모든 Room 생성을 try-with-resource 블록으로 감쌌다면 자동 청소는 전혀 필요하지 않다.