[이펙티브 자바] 규칙7. GC가 호출하는 Object.finalize()

자바의 최상위 클래스인 Object 클래스에는 finalize 메서드가 존재한다.

   /**
     * Called by the garbage collector on an object when garbage collection
     * determines that there are no more references to the object.
     * A subclass overrides the {@code finalize} method to dispose of
     * system resources or to perform other cleanup.
     * <p>
     * The general contract of {@code finalize} is that it is invoked
     * if and when the Java&trade; virtual
     * machine has determined that there is no longer any
     * means by which this object can be accessed by any thread that has
     * not yet died, except as a result of an action taken by the
     * finalization of some other object or class which is ready to be
     * finalized. The {@code finalize} method may take any action, including
     * making this object available again to other threads; the usual purpose
     * of {@code finalize}, however, is to perform cleanup actions before
     * the object is irrevocably discarded. For example, the finalize method
     * for an object that represents an input/output connection might perform
     * explicit I/O transactions to break the connection before the object is
     * permanently discarded.
     * <p>
     * The {@code finalize} method of class {@code Object} performs no
     * special action; it simply returns normally. Subclasses of
     * {@code Object} may override this definition.
     * <p>
     * The Java programming language does not guarantee which thread will
     * invoke the {@code finalize} method for any given object. It is
     * guaranteed, however, that the thread that invokes finalize will not
     * be holding any user-visible synchronization locks when finalize is
     * invoked. If an uncaught exception is thrown by the finalize method,
     * the exception is ignored and finalization of that object terminates.
     * <p>
     * After the {@code finalize} method has been invoked for an object, no
     * further action is taken until the Java virtual machine has again
     * determined that there is no longer any means by which this object can
     * be accessed by any thread that has not yet died, including possible
     * actions by other objects or classes which are ready to be finalized,
     * at which point the object may be discarded.
     * <p>
     * The {@code finalize} method is never invoked more than once by a Java
     * virtual machine for any given object.
     * <p>
     * Any exception thrown by the {@code finalize} method causes
     * the finalization of this object to be halted, but is otherwise
     * ignored.
     *
     * @throws Throwable the {@code Exception} raised by this method
     * @see java.lang.ref.WeakReference
     * @see java.lang.ref.PhantomReference
     * @jls 12.6 Finalization of Class Instances
     */
    protected void finalize() throws Throwable { }

 

특정 객체에 대한 참조가 더 이상 없다고 판단할 때 가비지 컬렉션이 객체의 finalize를 호출한다. 문서에서도 나와 있듯이 하위 클래스에서 시스템 리소스를 삭제하거나 다른 정리를 수행하기 위해 finalize 메서드를 오버 라이딩하여 작성할 수 있다.

	@Override
	protected void finalize() throws Throwable {
		// do something
		super.finalize();
	}

 

하지만 이펙티브 자바에서는 finalize 사용을 피하라고 권고한다.

finalize는 예측 불가능하며, 대체로 위험하고, 일반적으로 불필요하다.

 

finalize는 언제 수행되는지도 알 수 없으며 수행을 반드시 보장하지 않는다.

1. finalize 메서드는 호출되더라도 즉시 실행된다는 보장이 없으며, 언제 수행되는지도 알 수 없다.

 

finalize는 GC가 호출하게 되는데, GC는 JVM 구현마다 크게 다르기 때문에 finalize가 언제 수행되는지는 알 수 없다. 따라서 중요한 리소스의 해제를 finalize에서 하게 된다면 finalize가 언제 호출될지 모르기 때문에 애플리케이션 실행 중에 리소스 문제가 발생할 수 있으며, 발생하여도 재현하기가 쉽지 않아 디버깅하기 어렵다.

 

2. finalize 수행을 반드시 보장하지 않는다.

 

finalize가 호출되지 않은 상태로 애플리케이션이 종료될 수 있다. 그러므로 지속성이 보장되어야 하는 중요한 상태 정보를 finalize에 작성하면 안 된다. finalize를 반드시 수행하도록 하는 System.runFinalizersOnExit(), Runtime.runFinalizersOnExit() 메서드가 존재하지만, Deprecated 되었다.

     * @deprecated  This method is inherently unsafe.  It may result in
     *      finalizers being called on live objects while other threads are
     *      concurrently manipulating those objects, resulting in erratic
     *      behavior or deadlock.
     * @param value indicating enabling or disabling of finalization
     * @throws  SecurityException
     *        if a security manager exists and its <code>checkExit</code>
     *        method doesn't allow the exit.
     *
     * @see     java.lang.Runtime#exit(int)
     * @see     java.lang.Runtime#gc()
     * @see     java.lang.SecurityManager#checkExit(int)
     * @since   JDK1.1
     */
    @Deprecated
    public static void runFinalizersOnExit(boolean value) {
        Runtime.runFinalizersOnExit(value);
    }

 

 

finalize에서 발생하는 예외는 무시된다.

finalize 메서드 안에서 예외가 발생한다고 하더라도, 해당 예외는 무시되며 스택 트레이스도 표시되지 않는다. 또한 해당 finalize 메서드도 중단된다.

 

아래 예제를 보자.

public class ExceptionInFinalizeTest {

	public static void main(String[] args) throws Throwable {
		ExceptionInFinalizeTest exceptionInFinalizeTest = new ExceptionInFinalizeTest();
		exceptionInFinalizeTest = null;

		// System.gc does not guarantee finalize, but generally works fine.
		System.gc();
	}

	@Override
	protected void finalize() throws Throwable {
		System.out.println("The finalize method start");

		// Exceptions are ignored.
		System.out.println(2 / 0);

		super.finalize();

		System.out.println("The finalize method end"); // not printed
	}
}

 

ExceptionInFinalizeTest 객체를 생성하고, GC를 발생하도록 하기 위해 null로 하여 레퍼런스를 제거하였다. 이후 gc를 발생시켜 finalize()를 호출되게 하였다. finalize의 수행은 항상 보장하지는 않지만 테스트에서는 항상 호출되었다.

 

finalize에 예외를 발생시키도록 divde by zero를 수행하였지만, 어떠한 스택트레이스도 남지 않았으며 이후 코드도 수행되지 않고 종료된다.

 

 

finalize를 재정의할 경우 성능 저하가 발생한다.

finalize를 재정의 하는 것만으로도 성능 저하가 발생한다.

 

아래 에제를 보자.

public class FinalizePerformanceTest {

	/**
	 * TODO Implement performance test case for finalize
	 */
	public static void main(String[] args) {
		long start = System.nanoTime();
		for (int i = 0; i < 1000000; i++) {
			new FinalizePerformanceTest();
		}
		long end = System.nanoTime();
		System.out.println("time: " + (end - start));

	}

	@Override
	protected void finalize() throws Throwable {
		super.finalize();
	}

}

필자의 컴퓨터에서는 finalize를 재정의하여 테스트를 할 경우 위 결과는 152730300ns가 발생하였다. finalize 재정의를 하지 않을 경우 3501900ns 소요되었다. 약 43배 느리다.

 

finalize 사용방법 및 구현 방법

그럼 도대체 이렇게 단점이 많은 finalize는 어디에 사용할까?

 

1. 명시적 종료 메서드 패턴에서 호출되지 않을 것을 대비하기 위한 방어 역할

 

명시적 종료 메서드란 자원을 사용하고 나서 사용을 마쳤으면 메모리 해제를 명시적으로 하도록 만든 메서드를 의미한다. 대표적으로 FileInputStream, FileOutputSteam, Timer, Connection이 있다. 하지만 API 개발자는 항상 클라이언트가 API를 올바르게 사용하지 않을 수도 있다는 것을 고려해야 한다. 따라서 명시적으로 종료 메서드를 호출하지 않았을 경우를 대비하여 finalize 메서드에 메모리 해제를 하도록 작성한다.

 

아래는 java.io.FileInputStream 클래스의 코드이다.

public class FileInputStream extends InputStream
{
    ...

    /**
     * Ensures that the <code>close</code> method of this file input stream is
     * called when there are no more references to it.
     *
     * @exception  IOException  if an I/O error occurs.
     * @see        java.io.FileInputStream#close()
     */
    protected void finalize() throws IOException {
        if ((fd != null) &&  (fd != FileDescriptor.in)) {
            /* if fd is shared, the references in FileDescriptor
             * will ensure that finalizer is only called when
             * safe to do so. All references using the fd have
             * become unreachable. We can call close()
             */
            close();
        }
    }
}

 

2. 네이티브 피어(native peer) 리소스를 해제할 때

먼저 네이티브(native)란 자바 외의 C나 C++ 등 다른 언어로 작성된 프로그램을 나타낸다. 이런 프로그램을 자바에서 다루기 위해 만들어놓은 객체를 네이티브 피어라고 한다. 그리고 일반적인 클래스들이 이러한 네이티브 피어를 이용해 네이티브 프로그램을 사용한다.

 

이 네이티브 피어(객체)는 일반 객체가 아니기 때문에 GC가 관리하지 않는다. 그렇기 때문에 해당 네이티브 피어를 사용하는 일반적인 클래스의 finalize 메서드에서 해당 네이티브 객체의 리소스를 해제하는 코드를 작성할 수 있다.

 

 

finalize를 사용한다면 반드시 부모의 finalize를 호출해야 한다. 그렇지 않으면, 부모 클래스는 절대 종료되지 않는다.

	@Override
	protected void finalize() throws Throwable {
		try {
			// do something
		} catch (Exception e) {
			e.printStackTrace();
		} finally {
			super.finalize();
		}
	}

 

하지만 개발자는 항상 실수를 한다. 아래 예를 들어보자.

 

AClass는 finalize를 재정의하여 반드시 유한한 자원의 메모리를 해제해야 하는 클래스를 구현했다고 가정하자. AClass는 부모의 finalize를 반드시 호출해야 한다는 것을 알고 아래와 같이 구현하였다.

public class AClass {

	private void myClose() {
		System.out.println("Do Something");
	}

	@Override
	protected void finalize() throws Throwable {
		try {
			myClose();
		} catch (Exception e) {
			e.printStackTrace();
		} finally {
			super.finalize();
		}
	}

}

 

BClass는 AClass를 상속받고 마찬가지로 finalize를 재정의했다. 하지만 BClass는 실수로 super.finliaze()를 호출하지 않았다. 그럼 AClass의 finalize는 호출되지 않아 myClose는 호출되지 않는다.

 

이렇게 하위 클래스에서 잘못 코딩하여 발생할 수 있는 finalize 문제를 부모 클래스에서 막을 수 있는데 이를 Finalizer Guardian 패턴이라고 한다.

 

이는 GC의 기본원리를 이용하여 finalize를 호출하는 방식이다. 먼저 코드는 아래와 같다.

public class AClass {

	private final Object guardian = new Object() {
		@Override
		protected void finalize() throws Throwable {
			myClose();
		}
	};

	private void myClose() {
		System.out.println("Do Something");
	}

}

 

기존에 finalize에서 호출되었던 myClose() 메서드가 guardian이라는 변수에 선언된 익명 클래스의 finalize에 선언되어 있다. 즉, AClass의 자원 해제 역할을 익명 클래스가 대신한다.

 

A 클래스를 재정의한 B 클래스의 객체가 더 이상 레퍼런스가 없어 gc가 발생하게 된다면, B 객체에 존재하는 guaridan에 참조되어 있는 익명 클래스의 객체도 누구도 사용할 수 없다. 그러므로 익명 클래스의 객체도 gc 대상이 되므로 해당 finalize가 반드시 호출된다. 따라서 멍청한 하위 클래스가 부모의 finalize를 호출하지 않아도 문제가 발생하지 않는다.

 

 

요약

자원 반환에 대한 최종적 방어 로직 또는 네이티브 자원을 종료시키려는 것이 아니라면 finalize를 사용하지 말자.