https://www.itworld.co.kr/news/224419

몇 년 간의 무성한 소문 끝에 마침내 자바가 JDK 18에서 finalize 메서드를 퇴역시킬 준비를 하고 있다. JDK 향상 제안(Enhancement Proposal) 421은 finalize를 사용 중단되는 요소로 명시하고, 테스트를 위해 이 메서드를 비활성화하는 것을 허용한다. 기본적으로는 계속 활성화된 상태로 유지되다가 이후 릴리스에서 완전히 제거된다. finalize의 끝이 무엇을 의미하는지, 이제부터는 오류와 리소스 클린업을 어떻게 처리해야 하는지 알아보자.

ⓒ Getty Images Bank

finalize란 무엇인가

finalize가 왜 사라지는지, 그 대신 무엇을 사용해야 하는지를 이해하기 전에 finalize가 무엇인지부터 살펴보자. finalize의 기본적인 개념은 객체가 가비지 수집 대상이 될 때 실행되는 메소드를 객체에 정의할 수 있도록 하는 것이다. 기술적으로 객체는 [팬텀 도달 가능(phantom reachable)](http://www.cs.fsu.edu/~jtbauer/cis3931/tutorial/refobjs/about/phantom.html#:~:text=An object is phantomly reachable,been finalized%2C but not reclaimed.) 상태가 될 때, 즉 JVM에 강하거나 약한 참조가 남아 있지 않을 때 가비지 수집 대상이 된다. 이 시점에서 JVM이 object.finalize() 메서드를 실행하고 애플리케이션별 코드가 I/O 스트림이나 데이터스토어에 대한 핸들과 같은 리소스를 클린업한다는 개념이다.

자바의 루트 Object 클래스에는 equals(), hashCode() 등 다른 메소드와 함께 finalize() 메소드가 있다. 이 메소드의 용도는 모든 자바 프로그램이 만든 모든 단일 객체가 리소스 누출을 방지하기 위한 이 단순한 메커니즘에 참여할 수 있도록 하는 것이다. 예외가 발생하고 다른 클린업 코드가 누락된 경우에도 해당된다. 즉, 객체는 여전히 가비지 수집 대상으로 표시되고 최종적으로는 해당 객체의 finalize 메소드가 호출된다. 문제가 해결된 것이다. 그렇지 않은가? 리소스를 소비하는 객체에서 finalize() 메소드를 오버라이드하기만 하면 된다.

finalize 메소드의 문제

거기까지는 개념이다. 그러나 현실은 전혀 다르다. finalize에는 클린업 유토피아의 현실화를 막는 여러 단점이 있다. 이런 상황은 이론적으로는 좋아 보이지만 실제로 사용할 때 여러 문제를 일으킨다는 면에서 serialize() 메소드와 비슷하다. finalize의 문제점은 다음과 같다.

• finalize의 실행을 예측할 수 없다. 가끔 개발자의 생각과는 별개로 GC(Gargage Collector)가 객체에 더 이상 활성 참조가 없다고 멋대로 판단할 수 있다. 스택 오버플로우에 올라온 이 아찔한 답변이 대표적이다.
• finalize는 실행되지 않거나 한참 뒤늦게 실행될 수 있다. JEP 421 RFC에도 나와 있듯이 'GC는 일반적으로 메모리 할당 요청을 충족하기 위해 필요할 때만' 동작한다. 결국 GC의 변덕에 달려 있다.
• finalize는 죽은 클래스를 부활시킬 수 있다. 객체가 예외를 일으켜 GC 대상이 되는 경우가 종종 있다. 그러나 finalize() 메소드는 먼저 실행될 기회를 얻고, 무엇이든 할 수 있다. 여기에는 객체에 대한 활성 참조를 다시 설정하는 것도 포함된다. 잠재적으로 누출의 진원지가 될 수 있고 보안 측면에서 위험하기도 하다.
• finalize는 올바르게 구현하기가 어렵다. 제대로 기능하고 오류가 없는 finalize 메소드를 작성하기가 생각만큼 쉽지 않다. 특히 finalize의 스레딩 영향에 대해서는 아무런 보장이 없다. finalizer는 모든 스레드에서 실행이 가능하고 디버그하기가 매우 어려운 오류 조건을 일으킨다. finalize() 호출을 깜박 잊으면 발견하기 어려운 문제로 이어질 수 있다.
• 성능. finalize 동작의 불안정성을 감안하면 이를 지원하기 위한 JVM의 오버헤드를 감수할 만큼의 이득이 없다.
• finalize는 더 취약한 대규모 애플리케이션을 유발한다. 연구를 통해 입증된 바와 같이 finalize를 사용하는 대규모 소프트웨어는 취약할 가능성이 더 높고 무거운 부하에서 발생하는 재현하기 어려운 오류 조건에 직면할 가능성도 더 높다.

finalize가 사라진 이후

finalize 메소드가 퇴출된 이후 오류 처리와 클린업을 위한 적절한 방법은 무엇일까? 3가지 대안이 있다. try-catch-finally 블록, try-with-resource 문, 그리고 클리너(cleaner)다. 각 방법마다 장단점이 있다.

try-catch-finally 블록 : 리소스 해제를 처리하는 오래된 방법으로 try-catch 블록이 있다. 여러 상황에서 사용할 수 있는 방법이지만 오류가 빈번하고 장황하다는 단점이 있다. 예를 들어 중첩된 오류 조건(즉, 리소스 닫기 역시 예외를 유발하는 경우)을 완전히 캡처하려면 <리스트 1>과 같은 코드가 필요하다.