[모던 자바 인 액션] Chapter7. 병렬 데이터 처리와 성능

스트림을 사용하면 내부 반복으로 네이티브 자바 라이브러리가 스트림 요소의 처리를 제어할 수 있다. 따라서 개발자는 컬렉션 데이터 처리 속도를 높이려고 따로 고민할 필요가 없다. 컴퓨터의 멀티코어를 활용해서 파이프라인 연산을 실행할 수 있다는 점이 중요한 특징이다.

7.1 병렬 스트림

• 컬렉션에 parallelStream을 호출하면 병렬 스트림이 생성된다.
• 병렬 스트림이란 각각의 스레드에서 처리할 수 있도록 스트림 요소를 여러 청크로 분할한 스트림이다.
• 따라서 모든 멀티코어 프로세서가 각각의 청크 처리를 할당할 수 있다.

병렬 실행이 무조건 빠른 것은 아니다.

static long sum(int n) {
   long sum = 0;
   for (int i = 0; i < n; i++) {
      sum += 1;
   }
   return sum;
}

static long sequentialSum(long n) {
   return Stream.iterate(1L, i -> i + 1)
      .limit(n)
      .reduce(0L, Long::sum);
}

static long parallelSum(long n) {
   return Stream.iterate(1L, i -> i + 1)
      .limit(n)
      .parallel()
      .reduce(0L, Long::sum);
}

• 이 세 함수에 대해서 일반 반복 > 순차 스트림 > 병렬 스트림 순으로 속도가 빨랐다.
• 문제점
  • 반복 결과로 박싱된 객체가 만들어지므로 숫자를 더하려면 언박싱을 해야 한다.
  • 반복 작업은 병렬로 수행될 수 있는 독립 단위로 나누기가 어렵다.
    • 위의 iterate 연산은 이전 연산의 결과에 따라 다음 함수의 입력이 달라지기 때문에 청크로 분할하기 어려운 것이다.
    • 리듀싱 과정을 시작하는 시점에 전체 숫자 리스트가 준비되지 않았기 때문에 분할할 수 없는 것
    • 결국 순차 처리와 다를 게 없는데 스레드 할당 오버헤드만 증가

특화된 메서드 사용 LongStream.rangeClosed

static long sequentialSum(long n) {
   return LongStream.rangeClosed(1L, n)
      .reduce(0L, Long::sum);
}

static long parallelSum(long n) {
   return LongStream.rangeClosed(1L, n)
      .parallel()
      .reduce(0L, Long::sum);
}

•  LongStream.rangeColsed는 기본형을 직접 사용하므로 언박싱 오버헤드가 사라진다.
• LongStream.rangeColsed는 쉽게 청크로 분할할 수 있는 숫자 범위를 생산한다.
• 결과로 일반 반복 > 병렬 스트림 > 순차 스트림 순으로 빨랐다.

-> 올바른 자료구조를 선택해야 병렬 실행도 최적의 성능을 발휘할 수 있다.

 

병렬화가 공짜는 아니다.

• 스트림을 재귀적으로 분할
• 각 서브 스트림을 서로 다른 스레드의 리듀싱 연산으로 할당
• 이들 결과를 하나의 값으로 합치기
• 멀티 코어간 이동은 생각보다 비싸다.
• 따라서 코어간 데이터 전송보다 훨씬 오래 걸리는 작업만 병렬로 수행하는 것이 바람직

병렬 스트림은 올바르게 동작하려면 공유된 가변 상태를 피해야 한다.

static long sideEffectSum(long n) {
   Accumulator accumulator = new Accumulator();

   LongStream.rangeClosed(1, n).parallel().forEach(accumulator::add);

   return accumulator.total;
}

static class Accumulator {
   public long total = 0;

   public void add(long value) {
      total += value;
   }
}

• total에 접근할 때마다 (다수의 스레드에서 동시에 데이터에 접근하는) 데이터 레이스 문제가 일어난다.
• 성능은 둘째 치고 올바른 결괏값이 나오지 않는다.

병렬 스트림 효과적으로 사용하기

• 확신이 서지 않으면 직접 측정하라
• 박싱을 주의하라 (기본형 특화 스트림을 사용하자)
• 순차 스트림보다 병렬 스트림에서 성능이 떨어지는 연산이 있다.
  • limit나 findFirst처럼 순서 의존 연산은 병렬에서 비싼 비용을 치른다.
  • findAny가 더 성능이 좋다.
  • 정렬된 스트림에 unordered를 호출하면 비 정렬된 스트림을 얻을 수 있다. 요소 순서가 상관없다면 비정렬 스트림에 limit를 호출하는 것이 더 효율적이다.
• 스트림에서 수행하는 전체 파이프라인 연산 비용을 고려하라.
  • 처리 요소 수가 N이고 요소당 처리 비용이 Q일 때 총 처리 비용 = N*Q
  • Q가 높아진다는 것은 병렬 스트림으로 성능 개선 가능성이 있다.
• 소량의 데이터에서는 병렬 스트림이 도움이 되지 않는다.
• 스트림을 구성하는 자료구조가 적절한지 확인하라
  • LinkedList보다 ArrayList가 분해가 효율적이다.
  • range 팩토리 메서드로 만든 기본형 스트림도 쉽게 분해할 수 있다.
  • 커스텀 Spliterator를 구현해서 분해 과정 완벽 제어 가능
• 스트림의 특성과 중간 연산이 스트림을 어떻게 바꾸는지에 따라 분해 과정의 성능이 달라질 수 있다.
  • 필터 연산이 있으면 스트림 길이 예측이 어렵기 때문에 효과적으로 병렬 처리 가능한지 알 수 없게 된다.
• 최종 연산의 병합 과정 비용을 살펴보라.
  • 병합 비용이 비싸다면 병렬로 얻은 성능 이익이 상쇄될 수 있다.
• 병렬 스트림이 수행되는 내부 인프라 구조도 살펴봐야 한다.
  • 포크/조인 프레임워크