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
Sponsored
Surfshark
“유료 VPN, 분명한 가치 있다” VPN 선택 가이드
ⓒ Surfshark VPN(가상 사설 네트워크, Virtual Private Network)은 인터넷 사용자에게 개인 정보 보호와 보안을 제공하는 중요한 도구로 널리 인정받고 있다. VPN은 공공 와이파이 환경에서도 데이터를 안전하게 전송할 수 있고, 개인 정보를 보호하는 데 도움을 준다. VPN 서비스의 수요가 증가하는 것도 같은 이유에서다. 동시에 유료와 무료 중 어떤 VPN을 선택해야 할지 많은 관심을 가지고 살펴보는 사용자가 많다. 가장 먼저 사용자의 관심을 끄는 것은 별도의 예산 부담이 없는 무료 VPN이지만, 그만큼의 한계도 있다. 무료 VPN, 정말 괜찮을까? 무료 VPN 서비스는 편리하고 경제적 부담도 없지만 고려할 점이 아예 없는 것은 아니다. 보안 우려 대부분의 무료 VPN 서비스는 유료 서비스에 비해 보안 수준이 낮을 수 있다. 일부 무료 VPN은 사용자 데이터를 수집해 광고주나 서드파티 업체에 판매하는 경우도 있다. 이러한 상황에서 개인 정보가 유출될 우려가 있다. 속도와 대역폭 제한 무료 VPN 서비스는 종종 속도와 대역폭에 제한을 생긴다. 따라서 사용자는 느린 인터넷 속도를 경험할 수 있으며, 높은 대역폭이 필요한 작업을 수행하는 데 제약을 받을 수 있다. 서비스 제한 무료 VPN 서비스는 종종 서버 위치가 적거나 특정 서비스 또는 웹사이트에 액세스하지 못하는 경우가 생긴다. 또한 사용자 수가 늘어나 서버 부하가 증가하면 서비스의 안정성이 저하될 수 있다. 광고 및 추적 위험 일부 무료 VPN은 광고를 삽입하거나 사용자의 온라인 활동을 추적하여 광고주에게 판매할 수 있다. 이 경우 사용자가 광고를 보아야 하거나 개인 정보를 노출해야 할 수도 있다. 제한된 기능 무료 VPN은 유료 버전에 비해 기능이 제한될 수 있다. 예를 들어, 특정 프로토콜이나 고급 보안 기능을 지원하지 않는 경우가 그렇다. 유료 VPN의 필요성 최근 유행하는 로맨스 스캠은 인터넷 사기의 일종으로, 온라인 데이트나 소셜 미디어를 통해 가짜 프로필을 만들어 상대를 속이는 행위다. 이러한 상황에서 VPN은 사용자가 안전한 연결을 유지하고 사기 행위를 방지하는 데 도움이 된다. VPN을 통해 사용자는 상대방의 신원을 확인하고 의심스러운 활동을 감지할 수 있다. 서프샤크 VPN은 구독 요금제 가입 후 7일간의 무료 체험을 제공하고 있다. ⓒ Surfshark 그 외에도 유료 VPN만의 강점을 적극 이용해야 하는 이유는 다음 3가지로 요약할 수 있다. 보안 강화 해외 여행객이 증가함에 따라 공공 와이파이를 사용하는 경우가 늘어나고 있다. 그러나 공공 와이파이는 보안이 취약해 개인 정보를 노출할 위험이 있다. 따라서 VPN을 사용하여 데이터를 암호화하고 개인 정보를 보호하는 것이 중요하다. 서프샤크 VPN은 사용자의 개인 정보를 안전하게 유지하고 해킹을 방지하는 데 유용하다. 개인정보 보호 인터넷 사용자의 검색 기록과 콘텐츠 소비 패턴은 플랫폼에 의해 추적될 수 있다. VPN을 사용하면 사용자의 IP 주소와 로그를 숨길 수 있으며, 개인 정보를 보호할 수 있다. 또한 VPN은 사용자의 위치를 숨기고 인터넷 활동을 익명으로 유지하는 데 도움이 된다. 지역 제한 해제 해외 여행 중에도 한국에서 송금이 필요한 경우가 생길 수 있다. 그러나 IP가 해외 주소이므로 은행 앱에 접근하는 것이 제한될 수 있다. VPN을 사용하면 지역 제한을 해제해 해외에서도 한국 인터넷 서비스를 이용할 수 있다. 따라서 해외에서도 안전하고 편리하게 인터넷을 이용할 수 있다. 빠르고 안전한 유료 VPN, 서프샤크 VPN ⓒ Surfshark 뛰어난 보안 서프샤크 VPN은 강력한 암호화 기술을 사용하여 사용자의 인터넷 연결을 안전하게 보호한다. 이는 사용자의 개인 정보와 데이터를 보호하고 외부 공격으로부터 사용자를 보호하는 데 도움이 된다. 다양한 서버 위치 서프샤크 VPN은 전 세계 곳곳에 여러 서버가 위치하고 있어, 사용자가 지역 제한된 콘텐츠에 액세스할 수 있다. 해외에서도 로컬 콘텐츠에 손쉽게 접근할 수 있음은 물론이다. 속도와 대역폭 서프샤크 VPN은 빠른 속도와 무제한 대역폭을 제공하여 사용자가 원활한 인터넷 경험을 누릴 수 있도록 지원한다. 온라인 게임, 스트리밍, 다운로드 등 대역폭이 필요한 활동에 이상적이다. 다양한 플랫폼 지원 서프샤크 VPN은 다양한 플랫폼 및 디바이스에서 사용할 수 있다. 윈도우, 맥OS, iOS, 안드로이드 등 다양한 운영체제 및 디바이스에서 호환되어 사용자가 어디서나 안전한 인터넷을 즐길 수 있다. 디바이스 무제한 연결 서프샤크 VPN은 무제한 연결을 제공하여 사용자가 필요할 때 언제든지 디바이스의 갯수에 상관없이 VPN을 사용할 수 있다.