시스템 병렬화는 주의해서 적용하라

계산도 올바로 수행하고 성능도 빨라질 거라는 홛신 없이는 스트림 파이프라인 병렬화는 시도조차 하지 말라. 스트림을 잘못 병렬화하면 프로그램을 오작동하게 하거나 성능을 급격히 떨어뜨린다. 병렬화 하는게 낫다고 믿더라도 운영환경과 유사한 조건에서 수행해보며 성능지표를 계속 관찰하라. 정말정말 성능이 좋아진게 확실해졌을 때, 그럴때만 병렬화를 사용하라.

자바는 동시성 프로그래밍을 앞장 서서 지원해줬다. 자바 8부터는 아예 parallel 메서드를 호출하면 파이프라인을 병렬 실행할 수 있는 스트림을 지원해준다. 이처럼 자바로 동시성 프로그램을 작성하기는 점점 쉬워지지만,이를 올바르고 빠르게 작성하는 일은 여전히 여럽다.

//메르센 소수를 구하는 원래 코드
public static void main(String[] args) {
	primes().map(p -> TWO.pow(p.intValueExact()).subtract(ONE))
			.filter(mersenne -> mersenne.isProbablePrime(50))
			.limit(20)
			.forEach(System.out::println);
}

//parallel을 이용해 본다 
public static void main(String[] args) {
	primes().map(p -> TWO.pow(p.intValueExact()).subtract(ONE))
                        .parallel()
			.filter(mersenne -> mersenne.isProbablePrime(50))
			.limit(20)
			.forEach(System.out::println);
}

static Stream<BigInteger> primes() {
	return Stream.iterate(TWO, BigInteger::nextProbablePrime);
}

parallel을 이용해서 병렬로 실행했으니까 속도가 더 빨라졌겠지? 라고 생각할 수 있는데 성능 향상이 이루어지 않았고 CPU을 90% 사용하는 상태만 무한히 반복된다. 왜 이런 일이 발생하는걸까?

• 스트림 라이브러리가 이 파이프라인을 병렬화하는 방법을 찾아내지 못했다.
• 소스가 Stream.iterate이나 limit을 쓰면 파이프라인 병렬화로는 성능개선을 할 수 없다.
• 이 코드를 사용하면 새롭게 메르센 소수를 찾을 때 마다 그 이전까지의 원소 전부를 계산한 비용을 합친것 만큼 든다 (!!) → 스트림 파이프라인을 마구잡이로 병렬화하면 성능이 끔찍해진다.

1. 스트림의 소스가 ArrayList, HashMap, HashSet, ConcurrentHashMap의 인스턴스거나 배열, 범위, long 범위일 떄 병렬화의 효가가 가장 좋다.

   • 열거한 자료구조들 모두 다 데이터를 원하는 크기로 정확하고 손쉽게 나술 수 있기 때문에 일을 다수의 스레드에 분배하기 좋다.

     → 나누는 일은 Spliterator가 담당하고, Stream이나 Iterable 에서 가져올 수 있다.

   • 참조 지역성 또한 뛰어나다. → 원소의 참조들이 메모리에 연속해서 저장이 되어있다. → 참조지역성이 떨어지면 스레드는 데이터가 주 메모리에서(느림) 캐시 메모리로 전송되어 오기를 기다리고 있어 시간 낭비가 심하다. → 병렬화를 할 때 덩어리(벌크)로 떼 오기 때문에 참조지역성이 정말 중요하다!

2. 스트림 파이프라인의 종단 연산 동작 방식도 병렬 수행 효율에 영항을 준다.
   • 병렬화에 가장 적합한 연산은 min, max, count, sum 으로, 축약해서 완성된 형태로 제공한다.
   • anyMatch, allMatch, noneMatch처럼 조건에 맞으면 버로 반환라는 메서드도 적합하다.
   • 단, 컬렉션을 합치거나 하며 값을 변경하는 연산들(가변축소, stream.collect) 는 적합하지 않다.
   • 순차적인 연산이라면 병렬 수행의 효과는 떨어질 수 밖에 없다.

스트림을 잘못 병렬화하면 성능이 나빠질 뿐만 아니라 결과 자체가 잘못되거나 예상 못한 동작이 발생할 수 있다. (safety failure, 안전실패)

→ 안전실패는 병렬 파이프라인이 사용하는 mappers, filters 혹은 프로그래머가 만든 함수 객체가 명세대로 동작하지 않을 때 벌어질 수 있다. (이런 result가 나오겠지? 했으나 오류는 아닌데 예상했던 result와 다른 결과가 나온다)

→병렬처리로 구한 값들이 순서가 올바르지 않다면 forEach 말고 forEachOrdered 를 사용하자.

→ 데이터 소스 스트림이 잘 나눠지고, 병렬화하거나 빨리 끝나는 종단 연산을 사용하는 등 모든 조건이 완벽했더라도 파이프라인이 수행하는 진짜 작업이 병렬화에 드는 추가 비용을 상쇄하지 목한다면 성능 향상은 미미하다.

→스트림 병렬화는 오직 성능 최적화 수단이다. 성능 테스트를 필수로 진행하고, 운영 시스템과 흡사한 환경에서 테스트 하는게 좋다. 잘못된 파이프라인 하나가 시스템의 다른 부분의 성능까지 악영향을 줄 수 있다.

스트림 병렬화를 쓸 일이 적어질 것처럼 느껴질 것이다. 그건 진짜 그렇기 떄문이다. 스트림을 얼마나 많이 사용하는 코드이던, 스트림 병렬화가 효과를 보는 경우는 많지 않다.

// n보다 작거나 같은 소수의 개수를 계산하는 코드
static long pi(long n) {
	return LongStream.rangeClosed(2, n)
		.mapToObj(BigInteger::valueOf)
		.filter(i -> i.isProbablePrime(50))
		.count();
}

// parallel 사용
static long pi(long n) {
	return LongStream.rangeClosed(2, n)
		.parallel()
		.mapToObj(BigInteger::valueOf)
		.filter(i -> i.isProbablePrime(50))
		.count();
}

조건이 잘 갖춰진 위와 같은 코드에서는 병렬화의 효과를 볼 수 있지만, n이 커지면 이 방식으로 계산하는 건 좋지 못하다. 더 효율적인 레머의 공식 알고리즘이 있기 때문.

• 무작위 수들로 이뤄진 스트림을 병렬화 하려면 SplittableRandom 인스턴스를 사용하자. 병렬화하면 성능이 선형으로 증가하기 때문.
• ThreadLocalRandom은 단일 쓰레드에서 쓰고자 만들어졌기 때문에 SplittableRandom 만큼 빠르지 않다.
• 그냥 Random을 사용하면 최악의 성능이 나온다!