스트림 병렬화는 주의해서 적용하라 - [7장. 람다와 스트림(아이템48)]

📙 1. 자바의 동시성 프로그래밍

  자바는 동시성 프로그래밍 측면에서 항상 앞서갔다.

• 처음 릴리스된 1996년
  스레드, 동기화, wait/notify 지원
• 자바 5
  동시성 컬렉션인 java.util.concurrent  라이브러리와 실행자(Executor) 프레임워크 지원
• 자바 7
  고성능 병렬 분해(parallel decom-position) 프레임워크인 포크-조인(fork-join) 패키지 추가
• 자바 8
  parallel 메서드만 한 번 호출하면 파이프라인을 병렬 실행할 수 있는 스트림 지원

  이처럼 자바로 동시성 프로그램을 작성하기가 점점 쉬워지고 있다. 하지만, 동시성 프로그래밍을 할 때는 안전성(safety)과 응답 가능(liveness) 상태를 유지하기 위해 애써야 한다. 병렬 스트림 파이프라인 프로그래밍에서도 마찬가지다.

 

📙 2. 성공적인 스트림 파이프라인 병렬화

  스트림 파이프라인 병렬화의 효과를 먼저 알아보자.

  다음과 같이 n보다 작거나 같은 소수의 개수를 계산하는 함수가 있다고 해보자. 병렬화를 하지 않은 경우와 병렬화를 한 경우는 다음과 같다.

// 병렬화를 하지 않은 경우
static long pi(long n) {
    return LongStream.rangeClosed(2, n)
            .mapToObj(BigInteger::valueOf)
            .filter(i -> i.isProbablePrime(50))
            .count();
}

// 병렬화를 한 경우
static long pi(long n) {
    return LongStream.rangeClosed(2, n)
            .parallel()
            .mapToObj(BigInteger::valueOf)
            .filter(i -> i.isProbablePrime(50))
            .count();
}

  해당 코드를 이용하여 10^7(10_000_000)을 계산하였을 때, 병렬화 전에는 26초가 걸렸고 병렬화 후에는 10초가 걸렸다.

즉, 병렬화를 통해 2.6배의 성능 향상을 본 것이다.

 

📙 3. 잘못된 스트림 파이프라인 병렬화

  다음은 스트림 파이프라인 병렬화를 잘 못 사용한 예를 살펴보자.

  예시는 아이템 45(링크)에서 다루었던 메르센 소수를 생성하는 프로그램이다.

private static final int COUNT = 20;

public static void main(String[] args) {

    primes().map(p -> TWO.pow(p.intValueExact()).subtract(ONE))
            .filter(mersenne -> mersenne.isProbablePrime(50))
            .limit(COUNT)
            .forEach(System.out::println);
}

  이 코드도 병렬화를 한 경우가 병렬화를 하기 전보다 더 빨라졌을까?

  아니다. 병렬화를 하게 된다면 이 경우 아무것도 출력하지 못하면서 응답불가(liveness) 상태가 된다. 그 이유는 스트림 라이브러리가 이 파이프라인을 병렬화하는 방법을 찾아내지 못했기 때문이다.

  데이터 소스가 Stream.iterate 거나 중간 연산으로 limit을 쓰면 파이프라인 병렬화로는 성능 개선을 기대할 수 없다. 파이프라인 병렬화는 limit을 다룰 때 CPU 코어가 남는다면 원소를 몇 개 더 처리한 후 제한된 개수 이후의 결과를 버려도 아무런 해가 없다고 가정하기 때문이다. 다음 소수를 찾는 데 걸리는 시간이 이전 소수를 찾는 데 걸리는 시간보다 더 많이 거리기 때문에 병렬화가 제 기능을 발휘하지 못한 것이다.

 

📙 4. 스트림 파이프라인 병렬화를 적용하는 기준

  대체로 스트림 소스가 ArrayList, HashMap, HashSet, ConcurrentHashMap의 인스턴스 거나 배열, int 범위, long 범위일 때 병렬화의 효과가 가장 좋다. 이 자료구조들은 모두 데이터를 원하는 크기로 정확하고 손쉽게 나눌 수 있어서 일을 다수의 스레드에 분배하기 좋다는 특징이 있다.

  또한, 이 자료구조들은 원소들을 순차적으로 실행할 때 참조 지역성(locality of reference)이 뛰어나기 때문에 다량의 데이터를 처리하는 벌크 연산을 병렬화할 때 이점이 있다.

 

  스트림 파이프라인의 종단 연산의 동작 방식 역시 병렬 수행 효율에 영향을 준다. 종단 연산에서 수행하는 작업량이 파이프라인 전체 작업에서 상당 비중을 차지하면서 순차적인 연산이라면 파이프라인 병렬 수행의 효과는 제한될 수밖에 없다.

• 파이프라인에서 만들어진 모든 원소를 하나로 합치는 작업인 축소(reduction)가 병렬화에 적합한 종단 연산이다. (ex. min, max, count, sum)
• 조건에 맞으면 바로 반환되는 메서드도 병렬화에 적합하다. (ex. anyMatch, allMatch, noneMatch)
• 컬렉션을 합치는 부담이 큰 가변 축소(mutable reduction)는 병렬화에 적합하지 않다.

 

  스트림을 잘못 병렬화하면 (응답 불가를 포함해) 성능이 나빠질 뿐만 아니라 결과 자체가 잘못되거나 예상 못한 동작이 발생할 수 있다. 따라서, 계산도 올바르고 성능도 빨라질 거라는 확신 없이는 스트림 파이프라인 병렬화는 시도조차 하지 말자. 스트림을 잘못 병렬화하면 프로그램을 오동작하게 하거나 성능을 급격히 떨어뜨린다.

  또한, 병렬화를 하는 게 낫다고 판단이 되면, 운영 시스템과 흡사한 환경에서 테스트를 진행하도록 하자.

 

 

해당 글은 Joshua Bloch 님의 'Effective Java 3/E'를 참고하였습니다.