개발자 / 애플리케이션

'finalize 메소드 퇴역 이후' 자바 오류를 처리하고 클린업하는 방법

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

finalize란 무엇인가

finalize가 왜 사라지는지, 그 대신 무엇을 사용해야 하는지를 이해하기 전에 finalize가 무엇인지부터 살펴보자. finalize의 기본적인 개념은 객체가 가비지 수집 대상이 될 때 실행되는 메소드를 객체에 정의할 수 있도록 하는 것이다. 기술적으로 객체는 팬텀 도달 가능(phantom reachable) 상태가 될 때, 즉 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>과 같은 코드가 필요하다. 

과도해 보일 수 있지만 장기간 실행되고 사용량이 많은 시스템에서 이러한 종류의 오류 조건이 리소스 누출을 일으키고 궁극적으로는 앱을 멈추게 할 수 있다. 결국 코드베이스 전반에 걸쳐 이 장황함을 반복해야 한다. 코드플로우를 망치는 것으로 악명이 높다. 
 

<리스트 1> try-catch-finally로 리소스 닫기 처리 
FileOutputStream outStream = null;
try {
  outStream = new FileOutputStream("output.file");
  ObjectOutputStream stream = new ObjectOutputStream(outStream);
  stream.write //…
  stream.close();
} catch(FileNotFoundException ffe) {
  throw new RuntimeException("Could not open file for writing", ffee);
} catch(IOException ioe) {
  System.err.println("Error writing to file");
} finally {
  if (outStream != null) {
    try {
      outStream.close();
    } catch (Exception e) {
      System.err.println(“Failed to close stream”, e);
    }
  }
}


<리스트 1>에서 해야 할 일은 스트림을 열고 몇 바이트를 쓴 다음 어떤 예외가 발생하든 관계없이 확실히 닫히도록 하는 것이다. 이를 위해 try 블록으로 호출을 래핑해야 한다. 그리고 확인된 예외가 발생하면 래핑된 런타임 예외를 일으키거나 로그에 예외를 출력하는 방식으로 처리한다. 그런 다음 스트림을 재차 확인하는 finally 블록을 추가해야 한다. 이는 예외로 인해 닫기가 차단되지 않았는지 확인하기 위해서다. 그러나 단순히 스트림을 닫기만 할 수는 없고, 또 다른 try 블록으로 래핑해서 닫기 자체에서 오류가 발생하지 않도록 해야 한다. 이 방법이 간단하고 보편적인 필요를 충족하는 목적임을 감안하면 할 일이 너무 많고 번거롭다. 

try-with-resource 문 : 자바 7에 도입된 try-with-resource 문을 사용하면 try 선언의 일부로 하나 이상의 리소스 객체를 지정할 수 있다. 이 리소스는 try 블록이 완료될 때 닫힘이 보장된다. 구체적으로, java.lang.AutoCloseable을 구현하는 모든 클래스에는 try-with-resource를 사용할 수 있다. 자바 생태계에서 찾을 수 있는 보편적으로 사용되는 거의 모든 리소스에 적용할 수 있다. <리스트 1>을 다시 작성해 <리스트 2>와 같이 try-with-resource 문을 사용해 보자. 
 

<리스트 2> try-with-resouce로 리소스 닫기 처리 
try (FileOutputStream outStream = new ObjectOutputStream(outStream)) {
  ObjectOutputStream stream = new ObjectOutputStream(outStream);
  stream.write //…
  stream.close();
} catch(FileNotFoundException ffe) {
  throw new RuntimeException("Could not open file for writing", ffee);
} catch(IOException ioe) {
  System.err.println("Error writing to file");
}


이 방법에는 더 작은 코드 풋프린트로 이어지는 여러 이점이 있지만 가장 좋은 점은 try 블록 괄호 내에 선언하는 방법으로 스트림(또는 사용 중인 것 무엇이든)을 VM에 넘기고 나면 더 이상 신경 쓸 필요가 없다는 것이다. 알아서 닫힌다. 리소스 누출은 없다. finally 블록 또는 finalize 호출의 필요성을 없앴고, 이것으로 대부분의 사용 사례에서 가장 큰 문제가 해결된다(물론, 확인된 오류 처리의 장황함은 그대로 남는다). 너무 복잡해서 이와 같은 하나의 블록으로 처리할 수 없는 더 정교하고 견고한 해결책이 필요한 경우도 종종 있다. 그런 경우 자바 개발자는 더 강력한 해결책, 즉 클리너가 필요하다. 

클리너 : Cleaner 클래스는 자바 9에 도입됐다. 클리너를 사용하면 참조 그룹에 대한 정리 작업을 정의할 수 있다. 클리너는 Runnable에서 비롯된 인터페이스인 Cleanable 구현을 생성한다. 각 Cleanable은 예외를 무시하는 전용 스레드에서 실행된다. 클린업이 필요한 객체를 사용하는 코드와 클린업 루틴을 분리한다는 개념이다. 오라클 설명서에 나오는 <리스트 3>을 통해 더 명확히 살펴보자. 클리너에 대한 더 자세한 내용은 이 웹페이지를 참고하면 된다.
 

<리스트 3> 간단한 클리너 예 
public class CleaningExample implements AutoCloseable {
  // A cleaner, preferably one shared within a library
  private static final Cleaner cleaner = <cleaner>;
  static class State implements Runnable {
    State(...) {
      // initialize State needed for cleaning action
    }
    public void run() {
      // cleanup action accessing State, executed at most once
    }
  }
  private final State;
  private final Cleaner.Cleanable cleanable
  public CleaningExample() {
    this.state = new State(...);
    this.cleanable = cleaner.register(this, state);
  }
  public void close() {
    cleanable.clean();
  }
}


우선, 가장 중요하다고 할 수 있는 부분부터 시작하면 close() 메서드를 명시적으로 호출해서 참조를 정리할 수 있다. 이는 GC의 (모호한) 호출에 온전히 의존하는 finalize()와 가장 큰 차이다. close() 호출이 명시적으로 이뤄지지 않으면 시스템은 cleaner.register()의 첫 번째 인수로 전달된 객체가 팬텀 도달 가능 상태가 될 때 자동으로 이 호출을 실행한다. 그러나 개발자가 이미 명시적으로 실행한 경우 시스템은 close()를 호출하지 않는다(<리스트 3>의 코드는 AutoCloseable 객체를 생성한다. 이는 try-with-resource 문의 인수로 전달할 수 있음을 의미한다).

유의할 점은 클리너의 run 메소드에 클린업된 객체에 대한 참조를 생성해서는 안된다는 것이다. 생성할 경우 좀비 객체가 만들어질 가능성이 있기 때문이다(즉, 객체를 다시 활성으로 설정). <리스트 3>과 같은 형식에서는 그런 일이 발생할 가능성이 희박하지만 람다(람다는 이를 감싸는 범위에 접근이 가능함)로 구현하는 경우 가능성이 높아진다. 

그 다음 예시에 나온 “A cleaner, preferably one shared within a library(가급적이면 라이브러리 내에서 공유되는 클리너)”라는 주석에도 유의해야 한다. 이 주석을 붙인 이유는 각 클리너가 스레드를 생성하므로 클리너를 공유하면 프로그램 실행 오버헤드가 낮아지기 때문이다.마지막으로 모니터링되는 객체가 클린업 작업을 수행하는 코드로부터 분리되는 것을 볼 수 있다(<리스트 3>에서 State). 
 

finalize와의 작별 

자바는 계속해서 진화한다. 자바를 좋아하고 즐겨 사용하는 개발자에게 좋은 소식이다. finalize()의 퇴역과 새로운 접근 방법의 도입은 미래 관점에서 모두에게 좋은 신호다.

editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.