[이팩티브자바] 아이템 09. 리소스의 사용과 해제 : try-finally보다는 try-with-resources를 사용하라

💬 이팩티브자바 챕터 9를 읽고 정리한 글입니다.

---

✔️ 리소스는 어떻게 얻을 수 있을까?

흔히 자바에서는 리소스를 사용한 다음, catch를 통해 리소스를 사용하다 발생한 예외를 처리하고, finally에서 close()를 사용하여 직접 닫아주는 경우가 많다. (try-catch-finally) 이때, 닫아주지 않으면 클라이언트는 예기치 못한 성능 문제를 발견할 수도 있다. 

 

오라클 문서를 발췌해보면, 다음과 같은 문장이 존재한다.

The typical Java application manipulates several types of resources such as files, streams, sockets, and database connections. Such resources must be handled with great care, because they acquire system resources for their operations. Thus, you need to ensure that they get freed even in case of errors.
...
This leads to application servers being frequently restarted when resource exhaustion occurs, because operating systems and server applications generally have an upper-bound limit for resources.

: 리소스 획득 시 시스템 리소스를 획득하기 때문에 매우 주의해서 처리해야 하며, 오류가 발생하더라도 해제하도록 처리해야 한다. 또한, 보통 OS나 서버 애플리케이션에서는 리소스에 대한 상한치가 존재하기 때문에, 리소스 고갈이 발생하면 서버 자체가 재시작될 수도 있다는 점이다.

 

자바에서는 어떤 리소스들을 사용할 수 있을까? 크게 4가지로 나누어볼 수 있다.

1) 파일에 대한 리소스

- java.io 패키지를 사용하며, FileInputStream, FileOutputStream, BufferedReader 등을 활용하여 파일에 대해 읽고, 쓰기를 진행할 수 있다.

 

2) 네트워크 리소스

- java.net 패키지를 사용하며, Socket 등을 활용하여 서버와 연결하고 데이터를 송수신할 수 있다.

 

3) 데이터베이스 리소스

- java.sql 패키지를 사용하며, DB에 연결하고 데이터 조회 및 수정이 가능하다. 

 

4) 스레드 리소스

- java.lang.Thread 클래스를 사용하며, 스레드를 생성하고 실행할 수 있다.

 

이러한 리소스 획득을 위해서 JVM은 어떤 일들을 할까? 우선, 이를 알기 전에 간단하게 OS 커널에 대해서 알아보자. 

커널은 운영체제의 핵심 부분으로, 하드웨어와 소프트웨어 구성 요소 간의 상호 작용을 용이하게 한다. (위키피디아 발췌) 이때, 장치 드라이버를 통해 모든 하드웨어 리소스를 제어하고, 리소스의 활용을 최적화한다. 커널은 이런 중요한 역할을 하기 때문에, 사용자가 쉽게 접근할 수 없도록 '유저 모드 (User Mode)'와 '커널 모드 (Kernel Mode)'로 나누어, 2가지의 모드를 관리한다.

 

응용 프로그램은 주로 유저 모드에서, 그리고 자원에 대한 관리는 주로 커널 모드에서 이루어진다. 유저 모드는 우리가 응용 프로그램을 시작했을 때, 해당 응용 프로그램에 대한 프로세스를 실행하는 행위 등을 진행하며, 커널 모드는 메모리, CPU 같은 자원에 접근할 수 있으며 단일 virtual address space를 사용하기 때문에 장애가 발생하면 OS 전체가 충돌할 수 있다.

 

유저 모드와 커널 모드는 컨텍스트 스위칭이 발생하는데, 대략 아래와 같은 흐름으로 동작한다.

💬 시스템 콜이란?

운영체제 커널에서 제공하는 서비스를 사용하기 위해, 응용 프로그램이 호출하는 함수. 시스템 콜을 사용하면 응용 프로그램은 하드웨어의 리소스나 운영 체제의 자원에 직접 액세스할 수 있게 된다.

 

프로세스가 실행되는 동안, 특별한 요청이 필요하면 시스템 콜을 활용해서 커널에 요청을 하고, 커널은 해당 요청을 받아 요청에 대한 일을 처리한 다음, 결과값을 시스템 콜의 리턴값으로 전해주게 된다. 즉, 우리가 자바에서 파일에 대한 읽고 쓰기를 할 때 다음과 같이 동작하게 되는것이다.

 

1. 요청한 리소스의 종류에 따라서 그에 따른 시스템 콜을 호출한다.

2. OS로부터 리소스를 할당받는다.

3. 할당받은 리소스 관리를 위해, JVM은 해당 리소스 정보를 저장해둔다.

4. 해당 리소스를 사용할 때는, 리소스에 접근하기 위한 주소를 가져와서 사용하며, 사용이 끝난 리소스는 JVM 내부에서 삭제한 후 OS에 반환한다.

 

우리는 리소스가 OS와 밀접하게 연관되어 있기 때문에, 리소스의 할당뿐만 아니라 해제까지 중요하다는 점을 알 수 있었다. 이렇게 리소스의 할당과 해제 과정에서 알아보았으니, 실제 코드에서 어떻게 적용하는지 살펴보자. 

 

---

✔️ try-finally로 리소스 할당 및 해제하기

어느 날 져니는, 너무너무 심심한 나머지 백준에서 코딩 테스트를 풀려고 한다. 이때, 문자열에 대해 입력을 받는 문제를 보고 BufferedReader를 활용하여 InputStream으로부터 값을 입력받는 코드를 작성하려고 한다.

BufferedReader buf = new BufferedReader(new InputStreamReader(System.in));
try {
    String str = buf.readLine();
    /**
     *  ~ 그외 엄청나게 멋진 백준을 씹어먹을만한 알고리즘 코드 ~
     */
} finally {
    buf.close();
}

 

이 문제가 너무 마음에 들었던 져니는, 너무 감명받은 나머지 코드를 쓰다 말고 백준 씨에게 편지를 쓰기 위해 파일 입출력을 활용하기 시작했다.

BufferedReader buf = new BufferedReader(new InputStreamReader(System.in));
try {
    String str = buf.readLine();
    /**
     *  ~ 그외 엄청나게 멋진 백준 골드를 씹어먹을만한 알고리즘 코드 ~
     */

    OutputStream out = new FileOutputStream(dest);
    try {
        String letter = "안녕하세요, 저는 사실 백준을 너무 싫어합니다. 알고리즘을 왜 풀어야 하나요...?";
        byte[] bytes = letter.getBytes();
        out.write(bytes);
    } finally {
        out.close();
    }
} finally {
    buf.close();
}

그러나, 이런 식으로 자원이 2개 이상이 된다면 코드 자체가 너무 더러워지는 것을 볼 수 있다. 또한, 만약 내부의 OutputStream에서 예외가 발생하고 BufferedReader에서도 예외가 발생했다면, BufferedReader의 예외가 앞선 예외를 전부 집어 삼키게 되기 때문에 OutputStream에서 발생한 예외의 정보는 남지 않게 된다.

 

 

💬 예외 정보가 남지 않는지에 대한 테스트

간단하게 예외 정보가 실제로 남지 않는지에 대한 테스트를 진행해보자.

public class Main {
    public static void main(String[] args) throws IOException {

        BufferedReader buf = new BufferedReader(new InputStreamReader(System.in));
        try {
            String str = buf.readLine();
            /**
             *  ~ 그외 엄청나게 멋진 백준 골드를 씹어먹을만한 알고리즘 코드 ~
             */

            OutputStream out = new FileOutputStream(dest);
            try {
                String letter = "안녕하세요, 저는 사실 백준을 너무 싫어합니다. 알고리즘을 왜 풀어야 하나요...?";
                byte[] bytes = letter.getBytes();
                out.write(bytes);
                System.out.println("First!");
                throw new RuntimeException("Hello 1111");
            } finally {
                System.out.println("Second!");
                out.close();
            }
        } finally {
            buf.close();
            System.out.println("Third!");
            throw new RuntimeException("Hello 222");
        }
    }
}

결과를 보면, RuntimeException이 발생하기 전, 발생한 후, 그리고 마지막 finally 때 제어가 종료되면서 첫 번째 예외 throw (Hello 111)는 출력되지 않게 된다. 즉, 예외에 대한 정보가 집어 삼켜져 Hello 222만 실행된다.

 

여러모로 try-finally를 활용하는 구문은 불편하다. 이를 개선할 수는 없을까?

 

---

✔️ try-with-resources 활용하기

try-with-resource는 자바 7에서 새로나온 구조로, Autocloseable 인터페이스를 구현하면 해당 구조를 사용할 수 있게 된다.

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

AutoClosable은 내부에 close()라는 메서드만 덩그러니 놓여있는 것을 볼 수 있다. Autocloseable을 사용하게 되면, try 구문이 종료될 때 객체의 close() 메서드를 자동으로 호출하여 자원을 해제하도록 만들어준다.

 

이는, 자바 컴파일러가 컴파일 시점에 finally 블록에 자동으로 close() 코드를 추가해주며, 예외 발생 여부와 상관없이 실행하게 된다.

그렇다면, 아까의 코드를 리팩터링 하기 위해서는 내가 직접 Autocloseable 인터페이스를 구현해줘야 하는 것일까? 그것은 아니다. 자바 라이브러리와 서드파티 라이브러리들의 수많은 클래스, 인터페이스는 이미 AutoClosable을 구현하거나 확장해두었기 때문이다.

public interface Closeable extends AutoCloseable {
	...
}

public class BufferedReader extends Reader {
    public void close() throws IOException {
        synchronized (lock) {
            if (in == null)
                return;
            try {
                in.close();
            } finally {
                in = null;
                cb = null;
            }
        }
    }
}

// BufferedReader의 부모 클래스.
public abstract class Reader implements Readable, Closeable {
    private static final int TRANSFER_BUFFER_SIZE = 8192;
		...
}

// OutputStream
public abstract class OutputStream implements Closeable, Flushable {
	...
}

BufferedReader는 Reader를 상속받고, Reader는 Closeable을 상속받은 것을 볼 수 있다. 

그렇다면, 초기 코드를 어떻게 try-with-resources를 사용하도록 변경할 수 있을까?

 

[리소스를 1개만 사용한 경우]

try (BufferedReader buf = new BufferedReader(new InputStreamReader(System.in))) {
        String str = buf.readLine();
        /**
         *  ~ 그외 엄청나게 멋진 백준을 씹어먹을만한 알고리즘 코드 ~
         */
        }

[리소스는 2개 사용하는 경우]

try (BufferedReader buf = new BufferedReader(new InputStreamReader(System.in));
    OutputStream out = new FileOutputStream(dest)) {
    String str = buf.readLine();
    /**
     *  ~ 그외 엄청나게 멋진 백준 골드를 씹어먹을만한 알고리즘 코드 ~
     */
    String letter = "안녕하세요, 저는 사실 백준을 너무 싫어합니다. 알고리즘을 왜 풀어야 하나요...?";
    byte[] bytes = letter.getBytes();
    out.write(bytes);
}

다음과 같이 지저분한 코드는 모두 제거되고, try문 하나를 통해서 선언을 한 것을 볼 수 있다. (코드 자체가 매우 깔끔해진다)

 

여기서, 첫 번째 코드의 바이트코드를 살펴보자.

// class version 55.0 (55)
// access flags 0x21
public class Main {

    // compiled from: Main.java

    // access flags 0x1
    public <init>()V
            L0
    LINENUMBER 5 L0
    ALOAD 0
    INVOKESPECIAL java/lang/Object.<init> ()V
            RETURN
    L1
    LOCALVARIABLE this LMain; L0 L1 0
    MAXSTACK = 1
    MAXLOCALS = 1

    // access flags 0x9
    public static main([Ljava/lang/String;)V throws java/io/IOException
    TRYCATCHBLOCK L0 L1 L2 java/lang/Throwable
    TRYCATCHBLOCK L3 L4 L5 java/lang/Throwable
            L6
    LINENUMBER 7 L6
    NEW java/io/BufferedReader
            DUP
    NEW java/io/InputStreamReader
            DUP
    GETSTATIC java/lang/System.in : Ljava/io/InputStream;
    INVOKESPECIAL java/io/InputStreamReader.<init> (Ljava/io/InputStream;)V
    INVOKESPECIAL java/io/BufferedReader.<init> (Ljava/io/Reader;)V
    ASTORE 1
    L0
    LINENUMBER 8 L0
    ALOAD 1
    INVOKEVIRTUAL java/io/BufferedReader.readLine ()Ljava/lang/String;
    ASTORE 2
    L1
    LINENUMBER 9 L1
    ALOAD 1
    INVOKEVIRTUAL java/io/BufferedReader.close ()V
    GOTO L7
    L2
    LINENUMBER 7 L2
    FRAME FULL [[Ljava/lang/String; java/io/BufferedReader] [java/lang/Throwable]
    ASTORE 2
    L3
    ALOAD 1
    INVOKEVIRTUAL java/io/BufferedReader.close ()V
            L4
    GOTO L8
    L5
    FRAME FULL [[Ljava/lang/String; java/io/BufferedReader java/lang/Throwable] [java/lang/Throwable]
    ASTORE 3
    ALOAD 2
    ALOAD 3
    INVOKEVIRTUAL java/lang/Throwable.addSuppressed (Ljava/lang/Throwable;)V
            L8
    FRAME SAME
    ALOAD 2
    ATHROW
            L7
    LINENUMBER 10 L7
    FRAME CHOP 2
    RETURN
            L9
    LOCALVARIABLE buf Ljava/io/BufferedReader; L0 L7 1
    LOCALVARIABLE args [Ljava/lang/String; L6 L9 0
    MAXSTACK = 5
    MAXLOCALS = 4
}

여기서 중요한 부분만 대충 확인해보자.

위 코드는 BufferedReader와 InputStreamReader에 대해서 할당하고, 실행하는 부분이다.

그리고, 우리가 별도로 close()를 호출하지 않아도 컴파일러가 알아서 close() 메서드를 호출해준 것을 확인할 수 있다. (L1) 이때, L1에서 사용되는 close()는 BufferedReader가 상속받은 Reader 객체를 닫아주는 부분이다. 이때, Reader의 close()는 추상 메서드로 선언되어있기 때문에, 실제로 구현체인 BufferedReader의 close()를 사용하는 것을 볼 수 있다.

 

L2의 경우 L0와 L1 사이에서 발생하는 예외 클래스를 catch하는 부분으로, try-catch 블록의 시작점으로, 모든 예외의 최상위 클래스인 Throwable을 잡아서 처리하는 부분이다. 

L3는 BufferedReader 객체 자체를 닫으며 (마찬가지로 알아서 추가된 코드이다), L4에서는 예외 처리 후 L8으로 점프하게 된다. 

(L8에서는 예외 처리가 끝난 후, 마지막으로 실행되는데 여기서는 예외를 다시 로드해서 athrow를 통해 예외를 다시 발생시켜 다음으로 전파시키는 역할을 진행한다.)

L5에서는 예외가 발생했을 경우 발생한 예외 정보에 대해서 저장하고 addSuppressed() 메서드를 통해 추가해준다. 자원을 해제하는 도중에 예외가 발생했다면 해당 예외는 addSuppressed()를 통해 별도로 저장해두어 해당 예외의 상위로 추가한다.

 

💬 suppressed 예외

try-with-resources에서 자원을 닫는 도중에 예외가 발생한다면, try 블록에서 발생한 예외 앞에 추가되어 기록되며, 이러한 예외를 suppressed 예외라고 한다. 이는 기본 예외의 스택 트레이스에 표시되지 않고, getSuppressed() 메서드를 통해 접근이 가능하다. try 블록에서 발생한 예외와 함께 catch에서 처리가 가능하다. 코드로 예시를 확인해보자.

class CustomResource implements AutoCloseable {
    public void open() throws IOException {
        System.out.println("Resource opened!");
    }

    public void close() throws IOException {
        System.out.println("close() Call!");
        throw new IOException("close() Exception!!");
    }
}

public class Main {
    public static void main(String[] args) {
        try (CustomResource customResource = new CustomResource()) {
            customResource.open();
            System.out.println("~ Run Logic ~");
            throw new RuntimeException("try() Exception!!");

        } catch (Exception e) {
            System.out.println(e.getMessage());
            Throwable[] suppressed = e.getSuppressed();
            for (Throwable throwable : suppressed) {
                System.out.println("Suppressed: " + throwable.getMessage());
            }
        } finally {
            System.out.println("~ finally ~");
        }
    }
}

위 코드의 로직을 분석해보자.

1. try 블록을 실행한다.

- 초기에 open() 메서드가 호출된다, (Resource opened!)

- 이후, 어떠한 로직이 실행된다. (Run Logic)

2. 예외가 발생한다.

- 예외가 발생하고, try 블록이 끝나면서 close() 메서드가 호출된다.

- addSuppressed를 통해서 해당 예외에 대한 정보가 저장된다.

바이트 코드를 보면 위와 같이 실행되는 것을 볼 수 있다.

 

우리는 이렇게 다음과 같이 컴파일러가 알아서 close()를 호출해주는 것을 볼 수 있다.

추가적으로, catch를 통해서 예외를 처리하는 코드도 추가해보자.

 try (BufferedReader buf = new BufferedReader(new InputStreamReader(System.in));
             OutputStream out = new FileOutputStream("dest")) {
            String str = buf.readLine();
            /**
             *  ~ 그외 엄청나게 멋진 백준 골드를 씹어먹을만한 알고리즘 코드 ~
             */
            String letter = "안녕하세요, 저는 사실 백준을 너무 싫어합니다. 알고리즘을 왜 풀어야 하나요...?";
            byte[] bytes = letter.getBytes();
            out.write(bytes);
        } catch (IOException e) {
            // 예외 처리
        }
    }

그냥 기존이랑 똑같이 catch문을 통해서 원하는 예외를 처리하면 된다.

 

+) 참고로, 어차피 try-with-resources를 사용한다면 내부적으로 호출되는 close()에 의해서 IOException은 반드시 던지거나, 혹은 잡아서 처리해야 한다. (이는 checked Exception의 특징이기 때문에 당연한 것이다) 

이는, 자원을 해제하는 도중에 예외가 발생할 수도 있기 때문에 이러한 오류가 나는 것이며, catch를 선언하지 않거나 throws로 호출자에게 전달해주지 않으면 다음과 같이 오류가 발생한다. (위에서는 그냥 전파시켜서 내부적으로 ATHROW를 통해 전파시켰다)

 

💡 즉, try-with-resource는 컴파일러가 try 블록을 빠져나갈 때 자동으로 리소스를 해제해준다.
이때, 리소스를 해제하는 도중 예외가 발생하면 해당 예외는 먼저 처리하고, 그 뒤로 예외를 처리한다.
컴파일러는 finally 구문 내로 자원을 해제하는 코드를 추가한다.
그렇기 때문에 try에서 발생한 예외가 먼저 전달되고, 그 다음 finally에서 발생한 예외는 addSuppressed 메서드를 사용하여 try 블록에 발생한 예외에 추가된다.

---

마지막으로, 아래의 질문들을 정리하면서 정리해보자 🤔

 

✔️ try-with-resources를 사용했을 때 무엇이 좋았는가?

- 개발자가 직접 자원을 close()하는 구문을 작성하지 않아도 된다. (코드가 짧아지면서 가독성이 향상된다.)

- 자동으로 자원을 해제해주기 때문에 자원의 누수를 방지한다.

 

✔️ finally를 사용하는 것과 비교했을 때 장점은 무엇인가?

- 자원을 해제하는 코드를 직접 작성할 필요가 없다.

- 블록 내부에서 여러 개의 리소스를 열게 되면, 각각의 리소스에 대해 close()를 차례로 호출하게 되어 각 리소스의 해제 순서를 보장해준다.

 

✔️ GC가 관리해 주는데, try-with-resources를 사용하는 이유는?

- 가비지 컬렉터는 객체가 더 이상 사용되지 않을 때 자동으로 메모리를 해제해주기 때문에, 언제 해제될지에 대해서 보장해주지 않는다. 그렇기 때문에, 자원을 사용한 뒤에 빠르게 해제하기 위해서 직접 close() 메서드를 호출하는 것이 관습이며, try-with-resources를 사용하면 편하게 자원을 해제해줄 수 있기 때문에 사용하는 것이 더 좋다.