linuxism

NHN Business platform 웹플랫폼개발랩 문종호

2011년 7월 말 JDK 7이 정식으로 릴리스되었습니다. 비록 Lambda나 Jigsaw 같이 화제가 되었던 프로젝트는 JDK 8로 연기되어 김이 새긴 했지만, 무려 5년 만에 나오는 새 버전인 만큼 전세계 Java 개발자들의 이목이 집중되었습니다. 이 글에서는 JDK 7을 전체적으로 살펴보고, 주요 기능은 좀 더 심도 있게 알아보겠습니다.

JVM(Java Virtual Machine)에서 동작하는 언어는 Java만이 아니다. 기존 언어가 JVM에서 동작하도록 구현한 JRuby, Jython 같은 언어도 있고, Groovy, Scala 같이 처음부터 JVM 기반으로 만들어진 언어도 있다. 그러나 JVM에는 아직 Java에 의존적인 부분이 있기 때문에 다른 언어, 특히 동적 타입 언어가 JVM에서 동작하는 데 걸림돌이 되는 부분이 있었다.

InvokeDynamic은 이러 걸림돌을 제거하는 작업의 일환으로, JVM에서 동작하는 동적 타입 언어들의 효율성(바이너리 크기 등)과 성능 향상을 이끌어낼 것으로 보인다. 다만 동적 타입 언어의 제작자가 아닌 일반 개발자가 InvokeDynamic을 직접 사용할 일은 거의 없으므로 우리가 InvokeDynamic을 깊이 살펴볼 필요는 없을 것이다.

Java 개발자들이 가장 직접적으로 큰 변화를 느낄 수 있는 부분이 바로 Project Coin이다. Project Coin은 Java 언어에 작은 변화를 주어서 개발자들의 가려운 곳을 긁어주자는 목적으로 시작됐으며, 구체적인 변화 내용에 대해서는 Oracle 내부 개발자뿐 아니라 누구라도 참여할 수 있도록 공개적으로 제안서를 모집했다. 그 결과 70여 개의 제안서를 받았고, 그 중 다음과 같은 내용을 JDK 7에 포함했다.

• String in switch: switch 문에서 int와 Enum 외에 문자열도 사용할 수 있다.
• Binary integral literals and underscores in numeric literals: 2진수 리터럴 표현이 가능해지며, 모든 숫자 리터럴에서 언더스코어(_)를 사용하여 가독성을 높일 수 있다.
• Multi-catch and more precise rethrow: 하나의 catch 절에서 여러 타입의 예외를 처리할 수 있다.
• Improved Type Inference for Generic Instance Creation: Generic 객체를 생성할 때 타입 파라미터를 일일이 기술하지 않아도 된다.
• try-with-resources statement: try 절에서 사용되는 AutoClosable을 구현한 자원의 close() 메서드가 불리는 것을 보장하여 자원이 새는 것을 막는다.
• Simplified Varargs Method Invocation: 가변 인자 메서드와 generic이 만나서 발생하는 경고(warning)를 해결할 수 없는 경우가 있다. 이 경고를 해결하는 방법을 제공한다.

java.io.File을 대체할 java.nio.Path가 추가되며, 파일시스템과 관련된 많은 유틸리티 API, 비동기 채널, 파일 속성 관련 API, 파일시스템 감시(watcher) 기능 관련 API 등 많은 API가 추가된다.

Fork/Join 프레임워크를 포함하여 Java 동시성(concurrency)과 관련된 클래스가 추가된다.

그 밖에 한번 훑어볼 만한 기능은 다음과 같다.

• Upgrade class-loader architecture: 클래스 로더의 의존 관계에 사이클이 존재하면 데드락(deadlock)이 발생하는 문제를 피하도록 수정되었다.
• Locale enhancement: Java의 로캘(locale)은 현재 IETF BCP 47로 대체된 IETF RFC 1766 기반이다. 따라서 Java의 로캘을 IETF BCP 47 기반으로 변경했다.
• Unicode 6.0: Unicode 6.0을 지원한다.
• Enhanced JMX Agent and MBeans: JRockit에서 포팅된 기능으로, 방화벽 내의 MBean 서버에 접근할 수 있게 하고, VM에 대해 더 많은 정보를 제공하는 MBean을 제공한다.
• JDBC 4.1: JDBC 4.1로 업그레이드된다.
• Update the XML stack: JAXP, JAXB, JAX-WS의 최신 버전으로 업그레이드된다.

이 글에서는 이 중 Project Coin과 NIO.2, Fork/Join 프레임워크에 대해서 한층 더 깊이 살펴보도록 한다.

Project Coin에서 coin은 첫 번째 의미로 사용된다. Java의 문법에 새로운 뭔가를 만들어 넣는다는 것이다. 그래도 의문은 남는다. Project Lamda나 Project Jigsaw 등 다른 프로젝트들은 이름이 그 프로젝트의 내용을 나타내는데, Project Coin은 단지 '새로 만든다'라는 의미뿐이다. 이렇게 된 이유는 Project Coin의 시작과 진행 과정에서 찾을 수 있다.

Project Coin은 2008년 12월, 프로젝트 리더인 Joseph D. Darcy의 블로그 게시글에서 시작되었다. Sun(현재 Oracle)이 JDK 7에 '작은 언어 변화'를 포함시키기로 했는데, 구체적으로 어떤 변화를 줄 것인지는 공개적으로 제안서를 받아서 선정하겠다는 이야기였다. 그리고 여기에서 말하는 '작은 언어 변화'가 구체적으로 어떤 것인지, 제안서를 어떻게 써야 하는지 안내하는 게시글이 이어졌다. 그리고 2009년 2월 27일, Project Coin의 메일링리스트가 개설되었고 3월 30일까지 약 한 달 동안 70여 개의 제안서가 제출되었다. 같은 해 8월, 이 중 Project Coin에 포함될 제안서들이 확정되었다.

이처럼 Project Coin은 구체적으로 어떤 변화를 줄 것인지 정해놓고 시작한 것이 아니라 대중으로부터 제안을 받아 취합하는 형태로 진행된 프로젝트였기 때문에 이렇게 약간은 막연한 이름을 갖게 된 것이다.

이후 JDK 7의 진행이 지지부진해지면서 Project Coin도 함께 지지부진하게 진행되었다. 그리고 JDK 7과 JDK 8의 분리가 결정되면서 Project Coin도 JDK 7과 JDK 8에 포함될 것들로 구분했다. 다행히 JDK 8으로 연기된 기능은 Language support for collections 하나뿐이고, 나머지 기능들은 JSR 334에서 공식적인 절차에 따라 명세가 확정되었다.

그럼 이제부터 Project Coin의 기능들을 간단한 것부터 순서대로 살펴보도록 하겠다.

이 기능은 두 가지 내용을 담고 있다. 하나는 16진수 리터럴처럼 2진수 리터럴도 사용할 수 있게 하는 것이다. 16진수가 0x 또는 0X로 시작하는 것처럼 2진수는 0b 또는 0B로 시작한다.

다른 하나는 가독성을 높이기 위해 숫자 리터럴 중간에 언더스코어(_)를 넣을 수 있다는 것이다. 예를 들어 다음과 같은 상수를 보자.

한눈에 파악하기 쉽지 않다. JDK 7에서는 이를 다음과 같이 쓸 수 있다.

언더스코어는 숫자 사이 어디에든 넣을 수 있고, 언더스코어를 둘 이상 붙여서 쓸 수도 있다.

지금까지 switch 문에는 int와 Enum 타입만 사용할 수 있었지만 JDK 7부터는 String도 사용할 수 있다. 번잡한 if ... else ... 체인 대신 깔끔하게 switch 문을 사용할 수 있게 된 것이다. 다음은 String을 사용한 switch 문의 예이다.

만약 switch 문에 null 값이 들어오면(위 예제에서 code의 값이 null이면) NullPointerException이 발생한다.

문법적으로 더 설명할 만한 것은 없으나 Strings in switch가 어떻게 구현되는지 간단히 알아보자. Project Coin의 목표는 JVM 명세는 변경하지 않으면서 변화를 주는 것이다. 즉 Strings in switch는 자바 바이트코드 수준에서 지원되는 것이 아니라 컴파일러가 적절한 코드로 변환하는 것이다. 그런데 Project Coin은 이런 변환 과정이 어떻게 이루어지는지, 어떤 코드로 변환하는지는 언급하지 않고 있다. 컴파일러에 따라 최적의 방식으로 구현할 것이며, 우리는 구체적인 내용은 알 것 없이 그냥 쓰면 된다.

String을 사용할 수 있다면 그냥 모든 객체를 다 사용할 수 있게 하면 안 되는지 궁금해하는 사람들도 있을 것이다. 하지만 그렇게 만만한 일은 아니다. String을 지원하는 것은 자바 명세에 한 줄을 추가하는 것으로 끝났지만, Object를 지원하려면 훨씬 많이 변경해야 한다. 게다가 switch 문에서 굳이 Object를 사용해야 하는 경우가 있을까?

이 기능은 많은 사람들이 반길 만한 기능이다. 기존에 작성했던 다음과 같은 코드를 보자.

위 코드를 다음과 같이 작성할 수 있게 되었다.

즉, generic 객체를 생성할 때, 타입 파라미터를 명시하지 않아도, 컴파일러가 추론해서 자동으로 채워주는 기능이다. 물론, 모든 상황에서 가능한 것은 아니지만 OpenJDK, Tomcat, NetBeans 소스를 대상으로 테스트한 결과 약 90%정도는 정확하게 추론해냈다고 한다.

일반적으로 객체를 생성하는 경우는 다음과 같이 네 가지로 나눌 수 있으며, 네 경우 모두 diamond를 사용할 수 있다.

• 변수 선언

• 변수 대입

• 메서드 호출

• 반환

그러나 항상 이 기능을 사용하는 것이 바람직하지는 않을 것 같다. 메서드를 호출할 때, 특히 타입 파라미터를 가진 메서드를 호출할 때에는 상황이 복잡해질 수 있고, 최악의 경우 컴파일러가 추론에 실패하여 엉뚱한 타입을 집어넣거나 아예 컴파일 에러가 발생할 수도 있다. 이때에는 뭐가 잘못된 것인지 상황을 분석하기도 쉽지 않다고 한다.

하지만 변수 선언이나 대입의 경우에는 귀찮은 중복 코딩을 많이 줄여줄 유용한 기능이니 적극적으로 사용하길 권장한다.

이 기능은 매우 간단하지만 왜 필요한지 이해하기는 쉽지 않다. 바로 Generics가 얽힌 문제이기 때문이다. 한 문장으로 설명하자면 "비정형적인(non-reifiable) varargs 파라미터를 가지는 메서드의 varargs 파라미터에 비정형적인 타입의 값을 전달하여 호출하면 반드시 경고가 발생하는데, 이를 없앨 수 있는 방법을 제공하겠다"라는 것이다.

세 번째 줄에서 'Type safety : A generic array of Map<String, Object> is created for a varargs parameter'라는 경고가 발생한다. 무엇이 문제인지 알아보기 위해 asList() 메서드를 살펴보자.

아무리 봐도 잘못된 부분은 없다. 하지만 asList()를 호출하는 코드에 @SuppressWarnings("unchecked")를 삽입하는 것 외에는 저 경고를 제거할 수 있는 방법이 없다.

이 문제는 컴파일러가 varargs 메서드 파라미터를 배열로 변환하기 때문에 발생한다. asList()는 내부적으로 다음과 같이 변환된다.

실제로 이 코드를 직접 작성하여 컴파일하면 new Map<String, Object>[]에서 에러가 발생하고 컴파일이 중지된다. Java Generics에서 사용하는 type eraser 때문에 형 안전(type safe)하지 않은 상황이 발생할 가능성이 있어서 generic 배열을 생성할 수 없도록 했기 때문이다. 그런데 varargs 메서드를 처리할 때에는 컴파일러가 직접 이렇게 변환하고는 경고를 한다. 그러면 다음과 같은 문제가 발생한다.

위의 코드를 컴파일하면 경고만 하나 발생하고 컴파일이 완료된다. 그런데 이를 실행시키면 ClassCastException이 발생한다. 이는 doBadThing()에서 values에 ValueHolder<Integer>를 넣었기 때문이다. 그리고 컴파일러가 이를 막지 못한 것은 type eraser에 의해 values의 타입 파라미터 정보가 지워졌기 때문이다. 즉, 런타임에 VM이 values가 ValueHolder의 배열이라는 것만 알 뿐 ValueHolder<String> 배열이라는 것은 알 수 없다. 마찬가지로 ValueHolder<Integer>를 생성하더라도 런타임 시에는 이것이 ValueHolder로만 취급된다. 따라서 JVM이 보기엔 아무런 문제가 없다.

위 코드는 JVM에게 아래와 같은 코드로 보인다.

이제 어떤 문제가 발생할 수 있는지 알았다. 그런데 저런 일이 얼마나 일어나겠는가? 일부러 문제를 일으키려고 작정하지 않은 이상 이런 코드를 작성할 일은 거의 없다. 처음에 예를 든 Arrays.asList()에서도 이런 문제가 발생할 일은 전혀 없다. 그럼에도 불구하고 우리는 계속 무의미한 경고를 보지 않을 수 없었다.

JDK 7에서는 이러한 문제를 해결하기 위해 다음과 같은 조치를 취했다.

• non-reifiable한 varargs를 가지는 메서드의 호출뿐만 아니라 선언에도 경고를 발생시킨다.
• 해당 메서드에 아무런 문제가 없다면 메서드의 선언에 @SafeVarargs 어노테이션을 달 수 있다. 이 어노테이션을 달면 메서드의 선언과 호출에 경고가 발생하지 않는다.

다음은 @SafeVarargs의 사용 예제이다. 이 메서드를 호출하는 코드에는 경고가 발생하지 않는다.

@SafeVarargs를 아무데나 붙일 수 있는 것은 아니다. 다음 조건을 만족시키지 않는 메서드에 @SafeVarargs를 사용하면 컴파일 에러가 발생한다.

• varargs 메서드여야 한다
• final 메서드나 static 메서드여야 한다.

또한, 명세에서는 다음과 같은 메서드에 @SafeVarargs를 달면 컴파일러가 경고를 발생시키도록 권장하고 있다.

• varargs 파라미터가 reifiable 타입인 경우
• 위 예시 코드의 doBadThing()에서처럼 varargs 파라미터를 다른 변수에 대입하는 등 메서드에서 잠재적으로 문제의 가능성이 있는 연산을 수행하는 경우

당연히 JDK 7의 라이브러리에는 @SafeVarargs가 적용되어 있다. 다음은 @SafeVarargs가 적용된 메서드이다.

• public static <T> List<T> java.util.Arrays.asList(T... a)
• public static <T> boolean java.util.Collections.addAll(Collection<? super T> c, T... elements)
• public static <E extends Enum<E>> java.util.EnumSet<E> EnumSet.of(E first, E... rest)
• protected final void javax.swing.SwingWorker.publish(V… chunks)

이제 남은 두 가지 기능은 모두 try/catch 절과 관련된 것이다. 그 중에 Multi-catch and more precise rethrow는 두 가지 내용을 담고 있는데, 이는 어떤 한 가지 문제 상황을 해결하기 위한 것이다. 다음 예제를 통해 어떠한 문제인지 살펴보도록 하자.

someMethod()는 canThrowFooException()과 canThrowBarException()을 호출하며, 이 메서드들은 각각 FooException과 BarException을 던진다. 이들이 예외를 던지면 someMethod()는 이를 잡아 로그를 남긴 후 다시 던진다.

그런데 FooException과 BarException에 대한 catch 절이 완전히 동일하다. 중복을 줄이기 위해서 FooException과 BarException을 한꺼번에 처리할 수 있다면 좋을 것이다. 그래서 JDK 7에서는 다음과 같이 하나의 catch 절에서 여러 타입의 예외를 처리할 수 있는 multi catch 기능을 제공한다.

이때 e는 FooException과 BarException이 공통으로 구현한 모든 타입, 즉 공통의 조상 클래스를 상속받고 두 예외가 공통으로 구현한 인터페이스를 구현한 타입으로 취급받는다. 예를 들어 FooException과 BarException이 다음과 같이 선언되었다면 위 코드의 예외 파라미터 e는 ParentException를 상속받고 SomeInterface를 구현한 타입으로 취급된다.

이렇게 multi catch에 사용된 파라미터 e는 final로 선언되지 않았어도 암묵적으로 final로 취급된다. 물론 명시적으로 final로 선언해도 되지만 스타일상의 이슈로 final을 쓰지 않을 것을 권장하고 있다. 사실 예외 파라미터에 다른 값을 대입할 일은 거의 없기 때문에 문제가 되지는 않을 것이다.

multi catch와 관련한 또 하나의 제약 사항은 하나의 multi catch 절에서 처리하는 타입들 간에 부모 자식 관계가 존재하면 안 된다는 것이다. 예를 들어 다음과 같이 FooException과 그 부모 클래스인 ParentException을 함께 잡는 코드는 컴파일 에러가 발생한다. 하지만 이 역시, ParentException 하나만 잡으면 당연히 FooException도 같이 잡히기 때문에 굳이 둘을 같이 처리할 필요는 없으므로 별로 문제가 될 만한 제약은 아니다.

다시 처음에 제기했던 문제로 돌아가 보자. 사실 multi catch 없이 코드 중복을 막을 수 있는 방법도 있다. 다음 코드를 보자.

이렇게 하나의 catch 절에서 모든 예외를 잡으면 된다. 그런데 여기에서 새로운 문제가 발생한다. 이렇게 모든 예외를 잡아서 다시 던지려면 someMethod()도 예외를 던지도록 선언해야 한다. 문제는, 누가 봐도 FooException과 BarException 밖에 나올 수 없는데 컴파일러는 그냥 catch절만 보고 throws Exception을 선언해야 한다고 판단해 버린다는 것이다.

JDK 7에서는 바로 more precise rethrow로 이 문제를 해결했다. 이제 Java 컴파일러는 catch 절에서 다시 예외를 던질 때 다음과 같이 그 예외의 타입을 결정한다. catch 절에서 사용된 예외 파라미터가 다음 조건을 만족하면 위의 코드에서 someMethod()는 FooException과 BarException을 던진다고 선언할 수 있다.

• final이거나 effectively final이다. effectively final은 JDK 7에서 추가된 개념으로, final로 선언되지 않았지만 한 번 값이 할당된 후 변경되는 일이 없는 경우를 가리킨다.
• try 절에서 발생할 수 있다.
• 앞선 catch 절에서 잡은 것이 아니다.
• 예외 파라미터에 대입할 수 있다.

다음 예시에서 canThrowWhat()이 어떤 예외를 던진다고 선언해야 하는지, 즉 메서드 본문의 두 번째 catch 절에서 던지는 예외가 어떤 타입인지 결정되는 과정을 통해 이 규칙이 어떻게 적용되는지 살펴보겠다. 앞선 예시들에서 본 것처럼 canThrowFooException()과 canThrowBarException()은 각각 FooException과 BarException을 던지며, FooException과 BarException은 ParentException을 상속받는다. canThrowAnotherException()은 AnotherException을 던지며, AnotherException은 FooException, BarException, ParentException과는 아무런 관계가 없고 Exception을 직접 상속받는 예외이다.

• catch 절에서 예외 파라미터 e에 다른 값이 할당되지 않으므로 e는 effectively final이다.
• try 절에서 던지는 예외는 FooException, BarException, AnotherException이다.
• 앞선 catch 절에서 FooException을 잡으므로 남은 것은 BarException과 AnotherException이다.
• ParentException에 대입 가능한 것은 BarException이다.

따라서 canThrowWhat()은 BarException을 던진다고 선언하면 된다.

more precise rethrow와 관련해서 마지막으로 언급할 것은 이 기능 때문에 소스 레벨에서 하위 호환성이 깨진다는 점이다. 즉, JDK 6까지 문제 없이 컴파일이 되던 코드가 JDK 7에서는 컴파일이 되지 않을 수 있다. 하지만 걱정할 필요는 없다. 다행히도 이런 코드는 실제로는 전혀 있을 수 없는 코드이고, 실제로 수많은 소스코드를 검사하여 이런 패턴의 코드는 존재하지 않음을 확인했다고 한다. 그러면 도대체 어떤 코드에 문제가 발생하는 것인지 알아보자.

JDK 6에서는 두 번째 throw가 ParentException을 던진다고 판단하고 BarException을 잡는 catch 절이 실행 가능하다고 판단한다. 하지만 JDK 7에서는 두 번째 throw가 던지는 예외가 FooException이라고 더 정확하게 판단한다. 그 결과 BarException을 잡는 catch 절이 사용되지 않는 코드(dead code)임을 알아차리고 컴파일 에러를 발생시킨다. 즉, 실제로 잘못된 코드였으므로 컴파일되지 않는다고 해서 문제가 되진 않는다.

이제 Project Coin의 마지막 기능이자 말도 많고 탈도 많았던 try with resource이다. 이 기능은 자원을 사용한 후 적절하게 해제하는 것이 너무 어렵기 때문에 언어적으로 이를 지원하여 개발자의 실수를 줄여주자는 의도에서 도입되었다. Joshua Bloch는 이 기능을 제안하면서 Sun의 공식 문서에도 틀린 예제가 올라와 있었고, 자신이 쓴 책 Java Puzzler에서도 틀린 답이 있었는데 아무도 알아채지 못했을 정도로 자원을 관리하는 것은 어렵다고 말했다.

이 기능은 네 부분으로 이루어져 있으며, 첫 번째는 try with resource에 의해 자동으로 관리될 클래스가 구현해야 하는 AutoCloseable 인터페이스이다.

두 번째는 새로운 try with resource 문법이다. 다음과 같은 코드를 작성하면 try 블록 안에서 예외가 발생하든 발생하지 않든 resource.close()가 반드시 호출됨을 보장한다. 단, 여기서 SomeResource는 AutoCloseable을 구현한 클래스여야 한다.

세 번째는 Throwable 클래스의 변경이다. try 절에서 예외가 발생하여 자원의 close() 메서드를 호출했는데 거기서 또 예외가 발생한 경우, 최종적으로 던져지는 예외는 try에서 발생한 예외이다. 하지만 close()를 호출할 때 발생한 예외를 그냥 무시할 수도 없다. 이를 해결하기 위해 suppressed exception이라는 개념이 도입됐고, Throwable에 이와 관련한 메서드들이 추가되었다.

마지막으로, JDK의 플랫폼 라이브러리 중 각종 스트림과 채널 등 try with resource에 사용될 수 있는 모든 클래스는 AutoCloseable을 구현하도록 수정되었다. 특히 java.io.Closeable이 AutoCloseable을 상속받도록 수정됐기 때문에 Closeable을 구현한 모든 클래스는 자동으로 AutoCloseable을 구현하게 된다.

그럼 이제부터 try with resource에 대해 자세히 살펴보도록 하자.

try 뒤, SomeResource를 선언하고 있는 괄호 안을 자원 명세(Resource Specificaiton)라고 한다. 이 곳에서 AutoCloseable을 구현한 클래스들의 변수를 하나 이상 선언할 수 있다. 이 변수들은 암묵적으로 모두 final로 처리되기 때문에 반드시 이 곳에서 초기화되어야 한다. 또, 이 변수들의 scope는 자원 명세부와 try 블록으로 한정되기 때문에 catch와 finally 블록에서는 이 변수들이 보이지 않는다.

앞에서 언급했듯이 Project Coin은 JVM 명세를 전혀 변경하지 않는다. 따라서 try with resource도 컴파일러가 코드를 변환하는 방식으로 동작한다. 따라서 컴파일러가 이 코드를 어떻게 변환하는지 살펴보면 try with resource가 어떻게 동작하는지 알 수 있을 것이다. 이 코드만 이해하면 try with resource에 대해 모든 것을 파악한 것이나 마찬가지이다.

변환된 코드에서 알 수 있는 사실은 다음과 같다.

• 자원의 초기화 도중 예외 E가 발생하면 E가 전파된다. try 블록은 실행되지 않으며 자원의 close()도 호출되지 않는다.
• 자원의 초기화 도중 예외가 발생하지 않았고, 자원이 null이 아니면 자원의 close() 메서드는 반드시 호출된다.
• try 블록 안에서 예외 E가 발생하고 자원의 close() 메서드에서 예외가 발생하지 않으면 E가 전파된다.
• try 블록 안에서 예외 E가 발생하고 자원의 close() 메서드에서 예외 F가 발생하면 E가 전파되며 F는 E의 suppressed exception으로 추가된다 .
• try 블록 안에서 예외가 발생하지 않고 자원의 close() 메서드에서 예외 E가 발생하면 E가 전파된다.

또한 왜 자원 명세에 선언된 변수가 try 블록 안에서만 보이는지 알 수 있으며, final로 선언된 것도 확인할 수 있다.

앞에서 언급한 것과 같이, 자원 명세부에서 세미콜론(;)으로 구분하여 변수를 여러 개 선언할 수 있다. 이때 앞에서 선언한 변수를 뒤에서 사용할 수도 있다. 다음 코드에서 앞에서 선언한 some을 AnotherResource의 생성자에 전달하는 것이 그 예이다.

이렇게 여러 개의 자원을 선언했을 때 어떻게 동작하는지도 컴파일러가 이 코드를 어떻게 변환하는지 살펴보면 명확하게 알 수 있다. 컴파일러는 여러 개의 자원이 선언되었을 때 이를 재귀적으로 처리한다. 우선은 첫 번째 자원인 some에 대해서 앞에서 본 것과 같은 방법으로 변환한다. 이때 차이점은 안쪽 try가 자원 명세에서 some을 제외한 나머지 자원, 즉 another에 대한 try with resource라는 것이다.

자원이 세 개 선언되었다면 여기에서 변환이 한 번 더 일어난다. 이와 같은 방식으로 재귀적으로 처리한다.

이렇게 두 개 이상의 자원이 사용되었을 때 변환되는 코드를 살펴보면 다음과 같은 사실을 확인할 수 있다. 여러 자원을 선언했을 때 자원 명세에서 선언된 자원을 초기화하는 중에 예외 E가 발생하면 그 이후에 선언된 자원들은 초기화되지 않으며, 그 이전에 선언된 자원들 중 null이 아닌 자원에 대해서는 close()가 호출된다. 이 때 close() 호출 도중 예외가 발생하면 그 예외들은 E의 suppressed exception으로 설정되며 최종적으로 전파되는 예외는 E이다.

보통 이렇게 새로운 기능에 대한 설명을 듣고 나면 왠지 모든 문제를 해결해 줄 것이라는 기대를 갖게 된다. 하지만 이 세상에 완벽한 것은 없다. try with resource 명세 제정 과정에서 오고 간 논의의 한 토막을 살펴보자.

A: 자원을 자동으로 관리해 줄 수 있도록 try with resource를 만들자.

B: 그것으로는 lock을 처리할 수 없다.

A: 자원마다 사용하는 패턴이 다르다. try with resource는 획득 -> 사용 -> 반환의 패턴으로 사용되는 자원만 지원한다.

B: 일부에만 적용되는 복잡한 솔루션을 언어에 넣는 것은 바람직하지 않다. 게다가 JDK 8에 closure가 도입되면 언어에서 지원하지 않아도 라이브러리 수준에서 해결할 수 있는 문제이다.

A: 일부가 아니라 대부분의 자원에 대해 적용할 수 있으며, 그것만으로도 충분한 가치가 있다. 그리고 JDK 8까지 기다리기만 할 수는 없다.

간단하게 정리하니 별 내용 아닌 것 같지만 Project Coin 메일링리스트에서 가장 많은 메일이 오간 주제가 try with resource였다. 논란이 컸던 이유는 '자원'이라는 애매모호한 용어 때문이 아닐까 한다. 자원이라는 단어 하나가 가리키고 있는 것이 너무나도 많다. 스트림, 채널, 소켓, 메모리, 커넥션, lock 등이 모두 자원이고 그 특성이 제각각인데 그냥 하나로 묶어서 '자원'이라고 부르고 '자원을 자동으로 관리해 주겠다'라고 하니 듣는 사람들은 엄청난 걸 떠올릴 수 밖에 없다.

결론은 try with resource가 모든 자원 관리의 해법이 될 수는 없다는 것이다. 따라서 이 기능을 사용하고 싶다면 정말 try with resource의 패턴에 맞는 자원인지, 즉 한 번 획득해서 사용한 후 곧바로 반환해야 하는 자원인지 확인하고 사용해야 한다. 이렇게 적절한 자원에 try with resource를 활용하면 쉽게 안전한 코드를 작성할 수 있을 것이다.

우선 첫 번째로 살펴볼 것은 File 클래스를 직접 대체할 java.nio.file.Path이다. 이름에서 알 수 있듯이 파일보다는 경로 자체에 초점을 맞추고 있다. 실제로 Path의 메서드들을 보면 순전히 경로를 다루는 메서드뿐이라는 것을 알 수 있다. 사실 기존의 File 객체가 가리키는 것은 어떤 경로가 가리키는 대상일 뿐, 그게 진짜 파일인지는 알 수 없는 것이었으니 Path가 좀 더 정확한 의미일 것이다.

Path가 제공하는 메서드는 다음과 같이 분류할 수 있다.

• Path의 이름 요소 처리: getName(), getNameCount(), iterator()
• 관련된 Path 구하기: getFileName(), getParent(), getRoot(), subpath()
• 상대 경로 처리: relativize(), resolve(), resolveSibling()
• 경로 비교: compareTo() , startsWith(), endsWith()
• 경로 변환: normalize(), toAbsolutePath(),toRealPath()
• 타입 변환: toFile(), toString(), toUri()
• 기타: getFileSystem(), isAbsolute(), register()

"이름 요소"는 경로를 구성하고 있는 디렉터리 또는 파일명을 뜻한다. 즉 "foo/bar/sample.txt"라는 경로에서 이름 요소는 "foo", "bar", "sample.txt"이다. getNameCount()는 이름 요소의 개수를, getName(int)은 주어진 인덱스에 해당하는 이름 요소를 반환하는 메서드이다.

iterator()는 Iterable로부터 상속받은 메서드이며, 이 메서드를 호출하여 얻은 이터레이터는 경로의 이름 요소들을 순회하는 데 사용된다. 즉, "foo/bar/sample.txt"를 나타내는 Path의 이터레이터는 "foo", "bar", "sample.txt"를 차례로 반환한다.

Path는 또한 File을 사용하는 기존 코드와의 호환성을 위해 toFile()을 제공한다. 반대로 File에도 toPath()가 추가되었으니 File이 Path로 대체된다고 해서 호환성 문제가 생기지는 않을 것이다.

그런데 Path는 File과는 달리 클래스가 아니라 인터페이스이다. 그렇다면 Path는 어떻게 만들어 사용해야 할까?

파일시스템은 플랫폼에 따라 매우 다른 모습을 가지고 있다. 경로를 가리키는 문자열, 즉 Path를 생성하기 위해 사용되는 경로 표기법조차도 제각각이다. 따라서 플랫폼마다 적절하게 경로를 해석하여 Path를 생성하는 방법을 제공해야 한다. NIO.2는 FileSystem이라는 팩토리로 이 문제를 해결했다.

java.nio.file 패키지에는 FileSystem이라는 추상 클래스가 있다. 이 클래스의 getPath()가 바로 Path를 생성해주는 팩토리 메서드이다. JDK 7부터 JVM은 자신이 동작하는 플랫폼에 맞는 FileSystem을 기본 FileSystem으로 가지며, Path 등 파일시스템 관련 객체들은 기본 FileSystem을 통해 생성된다. 다음은 Path를 생성하는 예이다.

위 예에서 볼 수 있듯이 FileSystems.getDefault()를 호출하면 현재 플랫폼에 맞는 기본 FileSystem이 반환된다. 이 FileSystem을 사용하여 Path 등 파일시스템 관련 객체들을 생성해 사용하면 된다. 이렇게 매번 FileSystems.getDefault()를 호출하는 것이 번거로운 사람들을 위해서 Paths라는 유틸리티 클래스도 제공한다. 다음은 Paths를 사용하는 예이다.

기본 FileSystem이 있다는 이야기는 기본이 아닌 FileSystem도 있다는 뜻이다. 하나의 JVM에는 여러 개의 FileSystem을 등록하고 이를 사용할 수 있다. 하지만 대부분의 개발자들은 기본 FileSystem만으로도 충분할 것이다.

FileSystem은 Path 외에도 아직 설명하지 않은 NIO.2의 주요 타입들에 대한 팩토리 메서드들을 가지고 있다. Path 이외에 FileSystem으로 생성할 수 있는 객체는 다음과 같다.

표 1 FileSystem으로 생성할 수 있는 객체

Path에는 파일 관련 메서드는 없고 오직 경로와 관련된 메서드뿐이다. NIO.2에서 파일을 다루는 메서드는 모두 java.nio.file.Files에 있다. Files에는 많은 메서드들이 정의되어 있어서 이를 하나하나 살펴보기는 어렵다. 대신, 대부분의 유틸리티 클래스들이 그렇듯이 어떤 메서드가 있는지 알아두는 것만으로도 충분히 유용하기 때문에, 여기서는 간단하게 Files의 메서드들을 종류에 따라 분류하고 나열해 보도록 하겠다.

• 파일 연산
  • 파일을 이동/복사/삭제하는 move(), copy(), delete(), deleteIfExists()
  • 파일의 존재 여부를 체크하는 exists(), notExists()
  • 각종 파일시스템 구성 요소를 생성하는 createFile(), createLink(), createSymbolicLink(), createDirectory(), createDirectories()
  • 임시 파일과 디렉터리를 생성하는 createTempFile(), createTempDirectory()
• I/O
  • 파일 I/O를 위한 객체들의 팩토리 메서드 newInputStream(),newOutputStream(),newByteChannel(), newBufferedReader(), newBufferedWriter()
  • 파일을 한꺼번에 바이트 배열로 읽고 쓰는 readAllBytes(), write()
  • 파일의 모든 줄을 한꺼번에 읽고 쓰는 readAllLines(), write()
• 파일 속성
  • 파일의 특성을 체크하는 isDirectory(), isExecutable(), isHidden(), isReadable(), isRegularFile(), isSymbolicLink(), isWritable()
  • 파일 변경 시각을 조회, 설정하는 getLastModifiedTime(), setLastModifiedTime()
  • 파일의 크기를 조회하는 size()
  • 파일의 소유자를 조회하고 설정하는 getOwner().setOwner()
  • POSIX 파일 권한을 조회하고 설정하는 getPosixFilePermissions(), setPosixFilePermissions()
  • 위에 언급한 기본 속성뿐 아니라 플랫폼 종속적인 파일의 속성들까지 조회하고 설정하는 getAttribute(), getFileAttributeView(), readAttributes(), setAttribute()
• 디렉터리 탐색
  • Visitor 패턴으로 디렉터리를 탐색하는 walkFileTree()
  • 디렉터리의 엔트리들을 순회하는 데 사용하는 DirectoryStream의 팩토리 메서드 newDirectoryStream()
• 기타
  • 파일이 속한 FileStore를 반환하는 getFileStore()
  • 두 Path가 같은 파일을 가리키는지 확인하는 isSameFile()
  • 파일의 MIME 타입을 결정하는 probeContentType()
  • 심볼릭 링크가 가리키는 대상 Path를 조회하는 readSymbolicLink()

파일의 일부 속성은 거의 모든 플랫폼에서 동일하기 때문에 명시적인 API를 추가해도 큰 문제가 없다. 앞에서 살펴본 파일 속성 관련 메서드 중 대부분이 이러한 메서드이다. 하지만 이렇게 일반화하기 어려운 속성도 많다. 지금까지는 Java에서 이러한 속성에 접근할 수 있는 방법이 없었지만, NIO.2에서는 가능해졌다.

FileAttributeView

Java.nio.file.attribute 패키지에는 FileAttributeView와 그 하위 인터페이스들이 포함되어 있다. 각 인터페이스는 특정 파일 속성에 접근할 수 있는 메서드를 제공한다. 이름만 봐도 각 FileAttributeView가 어떤 속성을 다루는지 대략 짐작할 수 있을 것이다. 자세히 알고 싶다면 각 FileAttributeView의 javadoc을 살펴보기 바란다.

• FileAttributeView
  • BasicFileAttributeView
    • PosixFileAttributeView
    • DosFileAttributeView
• FileOwnerAttributeView
  • AclFileAttrivuteView
• UserDefinedFileAttributeView

FileAttributeView는 Files의 getFileAttributeView() 메서드를 호출해서 얻을 수 있다. 이때 원하는 FileAttributeView의 타입을 명시해야 한다.

플랫폼마다 지원하는 FileAttributeView가 다르므로 지원하지 않는 FileAttributeView를 요청하면 null이 반환된다. BasicFileAttributeView는 모든 플랫폼에서 제공된다. 어떤 FileAttributeView가 지원되는지 미리 확인하려면 다음과 같이 파일이 속한 FileStore를 통해 조회한다.

FileAttributeView를 직접 사용하지 않고 파일 속성들에 접근할 수 있는 방법도 있다. BasicFileAttributeView와 그 하위 인터페이스들이 제공하는 속성은 다음과 같이 Files의 readAttributes()를 호출하면 바로 가져올 수 있다.

Dynamic Access

모든 파일 속성에는 문자열로 표현되는 이름이 있다. 이 이름은 "{뷰 이름}:{속성 이름}"의 형식이며, 이렇게 이름으로 파일의 속성에 접근하는 것을 동적 접근이라 한다. 동적 접근을 위한 API도 Files에 있다. 다음은 DosFileAttribute의 hidden 속성을 가져오는 예이다.

setAttribute()을 사용하여 동적 접근으로 속성을 쓸 수도 있으며, readAttributes()로 여러 속성을 한꺼번에 읽어올 수도 있다.

NIO.2 이전에는 어떤 디렉터리의 엔트리들을 탐색하려면 File의 list() 또는 listFiles()를 호출하여 엔트리 목록을 한꺼번에 읽어 들여야 했다. 그래서 엔트리의 개수가 아주 많은 경우에는 메모리 관련 이슈가 발생하기도 했다. NIO.2에서는 이런 문제를 해결하고 좀 더 편리하게 디렉터리를 탐색할 수 있는 방법을 제공한다.

DirectoryStream

첫 번째 방법은 디렉터리의 엔트리들에 대한 이터레이터를 제공하는 DirectoryStream을 사용하는 것이다. 다음은 디렉터리 내의 모든 엔트리를 출력하는 예이다.

DirectoryStream를 사용하고 나면 위 예제처럼 반드시 close()를 호출해야 한다. 그렇지 않으면 자원의 누수로 시스템에 문제를 일으킬 수 있다. 그런데 자원을 반환하는 메서드를 제대로 호출하는 일은 생각보다 매우 어렵다. 그래서 앞에서 설명했듯이 JDK 7에는 try with resource라는 새로운 문법이 추가되었다. 이를 사용하면 try 또는 catch 절에서 예외가 발생하든 발생하지 않든, 사용한 자원의 close() 메서드가 반드시 호출되는 것을 보장한다. 다음은 JDK 7의 새로운 문법을 사용하도록 수정한 예이다.

DirectoryStream을 생성할 때, DirectoryStream.Filter 객체를 함께 전달하여 조건에 부합하는 엔트리만을 걸러내도록 할 수도 있다. 단순히 경로의 패턴을 가지고 엔트리를 걸러낼 경우 glob 패턴 문자열로 걸러낼 수도 있다. 다음은 DirectoryStream.Filter를 사용하여 디렉터리의 목록만을 출력하는 예이다.

FileVisitor

DirectoryStream은 대상 디렉터리에 직접 포함된 엔트리만을 순회하며, 하위 디렉터리의 내용은 포함되지 않는다. 만약 하위 디렉터리들까지 모두 탐색하려면 FileVisitor를 사용한다. 이름에서 알 수 있듯이 visitor 패턴을 사용하여 파일 트리를 탐색한다.

walkFileTree()는 주어진 디렉터리를 루트로 깊이 우선 탐색을 수행하며 FileVisitor의 메서드를 호출한다. 메서드 이름에서 알 수 있듯이 디렉터리에 들어가기 전에 preVisitDirectory(), 파일을 방문할 때 visitFile(), 디렉터리에서 나올 때 postVisitDirectory(), 어떤 이유에서든 파일 방문에 실패했을 때 visitFileFailed()가 호출된다. 방문 순서에 대해서는 깊이 우선 탐색이라는 점 이외에 정해진 것이 없다. 즉, 한 디렉터리 안의 엔트리들이 어떤 순서로 방문될 지 알 수 없으며, 심지어 파일과 디렉터리 중 어느 것이 먼저 방문될지도 알 수 없다.

FileVisitor의 각 메서드는 FileVisitResult라는 enum 타입을 반환하도록 선언되어 있으며, 이 반환값에 따라 파일 트리 탐색을 계속할지 결정한다. 위의 예처럼 CONTINUE를 반환하면 탐색을 계속하고, TERMINATE를 반환하면 탐색을 즉시 중단한다. SKIP_SUBTREE는 preVisitDiretory()에서만 사용할 수 있는 값으로 이 디렉터리 아래에 있는 것들은 탐색하지 말라는 의미이다. 마지막으로 SKIP_SIBLING은 현재 엔트리와 부모가 같은 엔트리들은 더 이상 탐색하지 않겠다는 의미이다.

WatchService

설정 파일이 변경되면 자동으로 감지하고 읽어 들여 반영시키라는 요구 사항이 있다면 어떻게 구현해야 할까? 이제까지는 파일을 읽어 들인 후 수정 시각을 기록하고, 타이머를 돌려 주기적으로 파일의 수정 시각을 체크하고, 수정 시각이 바뀌면 파일이 변경된 것으로 보고 파일을 읽어 들여야만 했다.

NIO.2는 이런 상황에 활용할 수 있는 WatchService를 제공한다. 다음은 D:\temp 디렉터리의 변경 사항을 모니터링하는 예이다.

다음은 위 코드의 각 단계에 대한 설명이다.

WatchService를 위의 예처럼 무한루프를 도는 전용 스레드에서만 사용해야 하는 것은 아니다. WatchService의 poll() 메서드를 사용하여 원하는 때에만 이벤트를 확인하는 방식으로 사용할 수도 있다. 또한, 감시할 대상이 하나뿐이라면 WatchService의 take()나 poll()을 호출할 필요 없이, register()를 호출할 때 반환된 WatchKey로 직접 pollEvents()를 호출해도 된다.

이처럼 WatchService를 사용하면 디렉터리 내에서 발생하는 이벤트들을 쉽게 통보받을 수 있어 상당히 유용하다. 하지만 WatchService는 디렉터리에 대해서만 사용할 수 있으므로 특정 파일만을 감시하고 싶을 때에는 약간 번거롭다. 감시할 파일의 부모 디렉터리에 ENTRY_MODIFY 이벤트에 대해 WatchService를 등록한 후, 이벤트가 발생하면 WatchEvent의 context()를 호출하여 이벤트가 발생한 파일이 내가 감시하고자 하는 파일이 맞는지 확인하는 과정을 거쳐야만 한다.

NIO.2는 세 가지 비동기 채널을 제공한다. AsynchronousFileChannel, AsynchronousServerSocketChannel, AsynchronousSocketChannel이며, 각각 FileChannel, ServerSocketChannel, SocketChannel의 비동기 버전이다. 즉, 다른 점은 모두 똑같고 I/O를 요청하는 메서드가 비동기로 동작하는 차이점만 있다고 보면 된다.

비동기 채널은 두 가지 패턴으로 사용할 수 있는데, Future를 사용한 방법과 CompletionHandler를 사용하는 방법이 있다. 모든 비동기 채널은 이 두 가지 패턴의 I/O 메서드를 지원하는데, I/O 메서드의 구체적인 시그니처는 각 채널의 특성에 따라 조금씩 다르다. 여기서는 혼자서도 간단하게 테스트해 볼 수 있는 AsynchronousFileChannel을 위주로 설명한다.

먼저 Future를 사용한 비동기 I/O 예를 살펴보자.

이처럼 비동기 채널은 Future를 반환하는 I/O 메서드를 가지고 있으며, 이를 호출하면 I/O 작업이 끝나지 않았더라도 즉시 Future를 반환한다. 그리고 다른 작업을 처리하다가 나중에 Future로부터 I/O 작업의 결과를 확인할 수 있다. Future를 사용하는 기존의 다른 API들과 다를 바 없다.

비동기 채널을 사용하는 또 다른 방법은 CompletionHandler를 사용하는 것이다. 이는 I/O 작업이 끝났을 때 호출할 콜백 함수를 등록하는 것이라 생각하면 된다. 예시 코드부터 살펴보자.

CompletionHandler를 사용하는 I/O 메서드를 호출하면, I/O 작업의 완료와 상관 없이 즉시 반환된다. I/O를 요청한 스레드는 이제 I/O를 신경쓰지 않고 다른 작업을 수행해도 된다. I/O가 완료됐을 때 다른 스레드에서 CompletionHandler의 메서드를 호출하여 뒤처리를 할 것이기 때문이다.

I/O가 성공적으로 완료되면 CompletionHandler의 completed()가 호출되고, 실패하면 failed()가 호출된다. completed()는 I/O 작업의 결과인 result와 I/O작업을 요청할 때 전달한 attachment를 파라미터로 받고, failed는 I/O 실패를 나타내는 예외와 함께 attachment를 파라미터로 받는다.

attachment는 I/O 요청과 완료 처리 간의 문맥을 유지시키기 위한 것으로, 어떤 값이든 전달할 수 있다. 위 예에서는 파일 읽기 작업을 요청하면서 읽기 버퍼를 attachment로 전달하므로 버퍼로 읽어 들인 값을 completed()에서 출력할 수 있다.

바로 앞에서 CompletionHandler는 다른 스레드에서 호출된다고 했는데, 이 스레드의 정체에 대해서 간단히 이야기해보자.

네트워크와 관련된 비동기 채널들은 모두 AsynchronousChannelGroup에 속한다. 같은 그룹에 속한 채널들은 스레드 풀 등의 자원을 공유하며, 바로 이 스레드 풀이 CompletionHandler를 호출한다.

채널을 생성할 때, 즉 AsynchronousSocketChannel이나 AsynchronousServerSocketChannel의 open()을 호출할 때, 새로 생성될 채널이 속할 AsynchronousChannelGroup을 지정할 수 있다. 채널이 속할 AsynchronousChannelGroup을 지정하지 않으면 시스템의 기본 그룹에 포함된다.

AsynchronousFileChannel도 마찬가지로 CompletionHandler 호출 등에 사용할 스레드 풀이 필요하지만 AsynchronousChannelGroup에 속하지 않는다. 대신 채널을 생성할 때, 사용할 ExecuterService를 지정할 수 있으며, 따로 지정하지 않으면 시스템 기본 스레드 풀을 사용한다.

재귀 알고리즘을 설명할 때 자주 사용되는 예인 병합 정렬을 예로 들어 Fork/Join이 어떤 것인지 감을 잡아보도록 하자. 두 개의 워커 스레드가 크기 4인 배열에 들어있는 데이터에 대해 병합 정렬(Merge Sort)을 수행하는 시나리오이며, M(a, b)는 배열의 a번째 값부터 b번째 값까지의 병합 정렬 작업을 나타낸다.

이것이 바로 work stealing이라는 정책으로, Cilk에서 처음 사용된 개념이다. 여러 스레드에 작업을 분배할 때, 어떤 작업이 얼마나 걸릴지 미리 예측하기 어렵기 때문에, 처음부터 각 스레드에 공평하게 작업을 분배해 준다는 것은 거의 불가능하다. 따라서 어떤 스레드는 일이 없어서 놀고 있는데, 어떤 스레드는 쉬지 않고 일해도 할 일이 산더미처럼 쌓여 있게 되는 상황이 벌어질 수 있다. 이런 경우에 놀고 있는 스레드가 바쁜 스레드의 작업을 가져다 처리하는 것이 work stealing이다. 따라서 각 프로세서에 골고루 작업이 분배되어 멀티프로세서 환경을 충분히 활용할 수 있다.

여기서 하나 눈여겨볼 점은, 다른 스레드의 작업 큐에서 작업을 훔쳐올 때는 큐의 반대쪽 방향에서 꺼내온다는 것이다. 여기에는 두 가지 이유가 있다. 하나는 작업 큐의 주인인 스레드와 작업을 훔쳐가려는 스레드 간의 경합을 피하기 위한 것이다. 다른 하나의 이유는 work stealing의 횟수를 줄이기 위한 것이다. Fork/Join 프레임워크의 특성상, 먼저 큐에 들어간 작업이 더 큰 작업일 가능성이 높다. 위의 그림에서는 큐의 가장 안쪽에 M(0, 1)이 있는데, 이 작업이 큐에 있는 작업들 중 가장 크기가 크다는 것을 알 수 있다. 자잘한 일을 훔쳐오면 금방 일이 끝나서 또 할 일이 없어져 또 다시 일을 훔쳐와야 하니, 되도록이면 큼직한 일을 가져와 이런 수고를 덜게 하는 것이다.

이제 Fork/Join 프레임워크의 실체를 살펴보기로 하자. 다음은 위에서 설명한 병합 정렬을 처리하는 코드이다.

우선 눈여겨봐야 할 코드는 main() 메서드에서 ForkJoinPool을 생성하고 invoke()를 호출하여 SortTask를 전달하는 부분이다. 이것이 앞에서 본 그림 중 첫 번째에 해당하는 부분, 즉 모든 것이 시작되는 부분이다.

그리고 SortTask의 compute() 메서드에서 하위 작업을 나타내는 SortTask 객체들을 생성하고 invokeAll()을 통해 이들을 호출하는 부분도 잘 살펴보기 바란다. invokeAll()은 인자로 전달된 모든 작업을 작업 큐에 넣고, 그들의 실행이 완료될 때까지 현재 작업을 멈추는 메서드이다. 앞의 그림 설명에서 '하위 작업들을 작업 큐에 넣고 현재 작업을 잠시 한쪽으로 치워두는' 것이 invokeAll()에서 이루어진다.

Fork/Join 프레임워크를 사용하기 위해 알아야 하는 것은 ForkJoinPool과 ForkJoinTask 둘뿐이다.

ForkJoinPool은 워커 스레드들을 관리하며, 외부에서 이 스레드 풀에 작업을 요청할 때 사용할 수 있는 API를 제공한다. 간단하게 말하자면, ForkJoinPool은 work stealing이 가능한 ExecutorService라고 할 수 있다. 실제로 ExecutorService를 구현하고 있기 때문에 Runnable이나 Callable 객체를 ForkJoinPool에서 실행시킬 수도 있다. 하지만 이 경우, ForkJoinPool의 혜택을 모두 누릴 수는 없다.

ForkJoinPool이 제공하는 효율적인 병렬 처리 효과를 제대로 보려면 ForkJoinTask를 사용해야 한다. ForkJoinTaks는 하위 작업을 작업 큐에 넣는 fork(), invoke(), invokeAll() 등의 메서드와 작업이 종료되길 기다릴 때 사용하는 join() 등의 메서드를 제공한다. 이를 활용하여 추상 메서드인 execute()를 구현하면 된다.

Fork/join 프레임워크는 ForkJoinTask를 상속한 RecursiveAction과 RecursiveTask도 제공한다. 예시 코드에서 사용된 RecursiveAction은 리턴값이 없는 재귀 작업을 좀 더 간단하게 구현하게 해주며 RecursiveTask는 리턴값이 있는 재귀 작업을 위한 것이다.

지면 관계상 각 클래스와 메서드들에 대해 깊이 살펴볼 수는 없으므로 관심 있으신 사람들은 JDK 7의 Javadoc을 살펴보기 바란다. Fork/Join 프레임워크 제작자인 Doug Lea가 Javadoc에 굉장히 상세한 설명을 달아놓았기 때문에 다른 레퍼런스가 거의 필요 없을 정도이다.

JDK 7에서 java.util.concurrent 패키지에 추가된 클래스는 위에 언급한 것들 외에 몇 가지가 더 있다. 이들은 대부분 Fork/Join 프레임워크의 구현에 필요하여 작성된 것이지만, 다른 곳에서도 유용하게 사용될 수도 있기에 포함된 것들이다. 이들에 대해 간단히 살펴보도록 하자.

• TransferQueue: BlockingQueue를 상속받은 인터페이스로, transfer() 메서드를 호출하여 큐에 값을 넣으면, 누군가가 그 값을 꺼내갈 때까지 블록되는 큐이다.
• LinkedTransferQueue: TransferQueue의 구현체이다.
• Phaser: CyclicBarrier와 유사하지만, 좀 더 유연하고 다양한 기능을 제공한다.
• ThreadLocalRandom: java.util.Random은 여러 스레드에서 동시에 사용할 경우 경합이 벌어져 성능에 영향을 줄 수 있다. ThreadLocalRandom은 이런 상황을 피할 수 있게 해준다.

NBP 웹플랫폼개발랩 문종호

세상만사 부질없으니 흘러가는 대로 흐르렵니다.

어쩌면 무력함에 대한 변명일 지도 모르겠습니다만, 그렇다면 그런 거지 뭐 있겠습니까.