try-with-resources 는 왜 사용해야할까?

글을 쓰게 된 이유

 

DB 접근 강의를 들으면서 네오가 키워드로 try-with-resources, AutoCloseable 를 던져주었다.

그래서 평상시에 try-with-resources를 그냥 사용하기만 했는데 이 기회에 좀 깊게 공부해보려고 한다.

 

try-with-resources는 무엇인가요?

 

try-catch-finally와 다르게 사용한 리소스에 대해서 명시적으로 close 하지 않아도 자동으로 close 해주는 것을 말합니다.

이펙티브 자바 아이템9 에서도 “try-finally 보다는 try-with-resources를 사용하라”는 말이 있습니다.

왜 try-with-resources를 사용해야 하는지 이번 글을 읽으면 깨달을 수 있습니다.

 

 

try-with-resources는 왜 사용해야하나요?

 

먼저 try-finally을 먼저 보도록 하겠습니다.

아래의 코드는 oracle에 나온 예시 코드입니다.

static String readFirstLineFromFileWithFinallyBlock(String path) throws IOException {
   
    FileReader fr = new FileReader(path);
    BufferedReader br = new BufferedReader(fr);
    try {
        return br.readLine();
    } finally {
        br.close();
        fr.close();
    }
}

정상적인 흐름이라면

FileReader 생성 → BufferedReader 생성 → try 문 실행 → BufferReader 닫힘 → FileReader 닫힘 과 같은 과정이 일어납니다.

 

“이렇게 close 제대로 해주면 문제없는 거 아니야?”라고 생각하실 수 있습니다.

그러나 이펙티브 자바에서도 실력 좋은 개발자도 close에 대한 처리를 가끔 잊어버릴 때가 있다고 합니다.

또한, close를 하지 않거나, 못하면서 생기는 2가지 문제가 있습니다.

 

첫 번째로, 리소스 누수입니다.

 

try 문에서 예외 발생 후, br.close()에서 예외가 발생한다면 fr.close()가 제대로 실행되지 않습니다.

그렇다면 GC가 리소스를 회수할 때, FileReader는 아직 close가 되지 않았기 때문에 사용되고 있다고 생각할 수 있습니다.

그래서 GC가 리소스를 회수하지 않게 되고, 이를 리소스 누수가 발생했다고 합니다.

 

두 번째로, exception suppressed에 의한 스택 추적 내역이 사라집니다.

try block 예외 → finally block 예외를 통해서 try block 예외가 finally block 예외에 의해 잡아먹히기 때문에 스택 추적 내역에는 첫 번째 예외에 관한 정보가 남지 않게 되면서 디버깅이 어렵게 됩니다.

 

이를 방지하기 위해 try-with-resources 문을 사용해야 합니다.

 

try-with-resources를 어떻게 사용하나요?

 

try-with-resources는 Closeable, AutoCloseable을 구현하는 객체들이 사용할 수 있는 것으로, 사용한 리소스들을 자동으로 반납해 줍니다.

즉, Closeable, AutoCloseable 인터페이스를 구현하는 모든 객체를 ‘리소스’의 대상이 되는 것이지요.

try-with-resources를 사용하기 위해서는 Closeable이나 AutoCloseable 인터페이스를 구현해야 합니다.

public interface Closeable extends AutoCloseable {
    public void close() throws IOException;
}

public interface AutoCloseable {
		void close() throws Exception;
}

Closeable 은 AutoCloseable을 상속받고 있습니다. 또한, Closeable은 IOException을 던지고, AutoCloseable은 Exception을 던집니다.

 

이렇게 예외가 확장된 것은 더욱 범용적으로 사용하기 위함이라고 생각합니다.

이 생각이 적합하다고 생각한 이유는 기존에 Closeable 패키지는 java.io였지만, AutoCloseable 패키지는 필수적인 클래스를 포함하는 java.lang에 존재하게 됩니다.

 

그래서 Closeable은 1.5, AutoCloseable은 1.7에 나오게 됐습니다.

 

try-finally Test

 

@Test
void test_exception_suppressed() throws Exception {

    Assertions.assertThrows(
            IllegalArgumentException.class,
            () -> exceptionSuppressed()
    );

}

void exceptionSuppressed() throws Exception {
    FileReader fr = new FileReader("src/main/resources/sql/schema.sql");
    BufferedReader br = new BufferedReader(fr);
    try {
        br.readLine();
        throw new IllegalStateException(); //exception
    } finally {
        br.close();
        throwException(); //exception 
        fr.close();
    }
}

void throwException() {
    throw new IllegalArgumentException();
}

try 문에서 예외가 발생하고, finally에서 예외가 발생했기 때문에 fr.close() 메서드가 호출되지 않아 리소스 누수가 생깁니다.

 

이때, try에서 던져진 예외는 suppressed 되고, finally에서 던져진 예외를 메서드가 던지게 됩니다.

 

try-with-resources 예시 코드

 

static String readFirstLineFromFile(String path) throws IOException {
	    try (FileReader fr = new FileReader(path);
	         BufferedReader br = new BufferedReader(fr)) {
	        return br.readLine();
	    }
	}

FileReader, BufferedReader는 AutoCloseable 인터페이스를 구현하고 있기 때문에 ‘리소스’의 대상이 됩니다. 또한, try 문이 정상적으로 완료됐는지에 상관없이 close 메서드를 호출합니다.

 

테스트를 통해 확인해 보겠습니다.

@Test
void test_try_with_resources() throws Exception {
    Assertions.assertThrows(
            IllegalArgumentException.class,
            this::tryWithResources
    );
}

void tryWithResources() throws Exception {
    try (FileReader fr = new FileReader("src/main/resources/sql/schema.sql");
         B b = new B();
         A a = new A(); //예외 발생
         BufferedReader br = new BufferedReader(fr)) {

        System.out.println("여기까지 옴");
        br.readLine();
        throw new IllegalArgumentException(); //예외 발생
    }
}

static class A implements AutoCloseable {

    @Override
    public void close() throws Exception {
        throw new IllegalStateException();
    }
}

static class B implements AutoCloseable {
    @Override
    public void close() throws Exception {
        System.out.println("예외 터져도 실행됨");
    }
}

위 코드에는 try-with-resources와 try block 안 모두 예외가 발생한 상황입니다.

 

try block 안이 실행되고 close 되면서 exception 이 발생합니다.

try-with-resources는 생성할 때의 리소스 반대로 close 메서드를 출력하기 때문에

br → a → b → fr 순서로 close 메서드를 호출하게 됩니다.

 

아래 로그를 보면 신기하게 a에서 예외가 발생해도 b의 close가 제대로 실행됨을 알 수 있습니다.

 

그 이유는 try block에서 발생한 예외를 던지고, try-with-resources에서 발생한 예외는 suppressed 되기 때문입니다.

그래서 try-finally 사용과 반대로 try 문의 예외가 먹히지 않아서 스택 추적 예외에서 사라지지 않기 때문에 디버깅이 전보다 나아집니다.

 

만약에 try-with-resources 문에서 바로 예외가 발생하면 어떻게 될까요?

static class A implements AutoCloseable {

		// 이 부분만 다름
    public A() {
        throw new IllegalStateException();
    }

    @Override
    public void close() throws Exception {
        throw new IllegalStateException();
    }
}

@Test
void test_try_with_resources() throws Exception {
    Assertions.assertThrows(
            IllegalStateException.class,
            this::tryWithResources
    );
}

위 예시 코드 대부분 비슷하고, A를 생성할 때 바로 예외를 던져보도록 하겠습니다.

실행을 시키면 당연히 IllegalStateException 가 발생하게 됩니다.

 

 

신기한 것은 B의 close 메서드가 실행됩니다.

예외가 발생하기 전까지의 try-with-resources의 close 메서드를 호출해 줍니다.

 

이러한 점 때문에 리소스 누수가 생길 수 있는 try-catch-finally 보다 try-with-resources를 사용하라고 합니다.

 

 

REFERENCES

oracle 문서