Stream API와 병렬 처리

2. 핵심 원리

2.1 스트림 vs 컬렉션

내부 반복이 핵심입니다. for (Order o : orders) 는 "어떻게 순회할지"를 개발자가 씁니다. orders.stream().filter(...) 는 "무엇을 원하는지"만 쓰고 순회 방법은 라이브러리에 맡깁니다. 그래서 라이브러리가 병렬화, 단락 평가(short-circuit), 연산 융합 같은 최적화를 할 수 있습니다.

2.2 파이프라인 구조 — 생성, 중간, 최종

   소스(생성)          중간 연산(0개 이상)                     최종 연산(정확히 1개)
┌────────────┐    ┌────────┐   ┌───────┐   ┌────────┐    ┌──────────────┐
│ list.stream()│──►│ filter │──►│  map  │──►│ sorted │───►│ collect / sum│──► 결과
└────────────┘    └────────┘   └───────┘   └────────┘    └──────────────┘
                    Stream 을 반환 (체이닝)                   Stream 이 아닌 값 반환

중간 연산은 파이프라인 설계도를 쌓을 뿐 아무것도 실행하지 않습니다. 최종 연산이 그 설계도를 보고 소스에서 요소를 하나씩 끌어와 모든 단계를 통과시킵니다.

2.3 지연 평가(Lazy Evaluation) — 증명 코드

"중간 연산은 최종 연산 전까지 실행되지 않는다"와 "요소는 한 개씩 전체 파이프라인을 통과한다"를 peek 으로 눈으로 확인합니다.

Stream<String> s = Stream.of("a", "bb", "ccc", "dddd")
    .peek(x -> System.out.println("filter 전: " + x))
    .filter(x -> x.length() >= 2)
    .peek(x -> System.out.println("  map 전: " + x))
    .map(String::toUpperCase);
System.out.println("--- 아직 아무것도 출력 안 됨 ---");
List<String> result = s.limit(2).toList();     // 최종 연산: 여기서 실행
System.out.println(result);
// 출력:
// --- 아직 아무것도 출력 안 됨 ---
// filter 전: a
// filter 전: bb
//   map 전: bb
// filter 전: ccc
//   map 전: ccc
// [BB, CCC]

관찰 포인트:

1. 최종 연산 전에는 peek 이 한 줄도 찍히지 않았습니다.
2. a 는 filter 를 통과 못 해 map 까지 가지 않았습니다.
3. limit(2) 가 채워지자 dddd 는 아예 읽지도 않았습니다(단락 평가). 컬렉션 방식이라면 4개 전부 filter → 전부 map → 2개 자르기였을 것입니다.

즉 스트림은 "단계별로 전체를 처리"(수평)가 아니라 "요소별로 전체 단계를 처리"(수직)합니다. 이 덕에 무한 스트림도 limit 만 있으면 끝납니다.

2.4 스트림 생성

2.5 중간 연산(Intermediate Operations)

무상태 vs 유상태: filter, map 은 요소 하나만 보고 결정하므로 병렬화가 쉽고 메모리를 안 씁니다. sorted, distinct 는 이전 요소를 기억해야 하고 특히 sorted 는 모든 요소가 도착할 때까지 다음 단계로 못 넘깁니다(파이프라인 장벽). 무한 스트림에 sorted 를 붙이면 영원히 끝나지 않습니다.

takeWhile vs filter: filter(x -> x < 5) 는 끝까지 다 봅니다. takeWhile(x -> x < 5) 는 처음 실패하는 순간 멈춥니다. 정렬된 데이터에서는 takeWhile 이 압도적으로 효율적입니다.

flatMap: List<Order> 에서 각 주문의 List<Item> 을 전부 꺼내 하나의 Stream<Item> 으로 만듭니다. map 을 쓰면 Stream<List<Item>> 이 됩니다.

2.6 최종 연산(Terminal Operations)

Optional 을 반환하는 최종 연산(min, max, findFirst, findAny, reduce(op))은 빈 스트림일 수 있어서 그렇습니다. null 대신 "없을 수 있음"을 타입으로 강제하는 것입니다(05 레슨).

2.7 Collectors 딥다이브

collect 는 "요소들을 어떻게 누적할지"를 Collector 로 받습니다. Collectors 유틸이 대부분 제공합니다.

toMap 키 충돌: 고객 이름 → 주문 맵을 만들 때 같은 고객이 두 번 나오면 예외입니다. 운영에서 데이터가 늘어나면 어느 날 갑자기 터지는 전형적인 사고입니다. 반드시 mergeFn 을 주거나((a, b) -> b 마지막 승, Long::sum 합계) 그룹핑을 쓰세요.

groupingBy 다단계: downstream 자리에 또 groupingBy 를 넣으면 2단 맵이 됩니다. groupingBy(Order::month, groupingBy(Order::category, summingLong(Order::amount))) → Map<Month, Map<Category, Long>>.

teeing: 평균과 개수를 동시에, 또는 최소·최대를 한 번의 순회로 얻을 때 씁니다. teeing(minBy(cmp), maxBy(cmp), (min, max) -> ...).

2.8 기본형 스트림 — 박싱 비용

Stream<Integer> 는 요소마다 Integer 객체입니다. 백만 개면 백만 개 객체 + 언박싱. IntStream, LongStream, DoubleStream 은 기본형을 그대로 다룹니다.

숫자 계산이 있으면 mapToInt/Long/Double 로 내려가서 처리하는 것이 관례입니다. summaryStatistics() 는 한 번의 순회로 count/sum/min/max/average 를 전부 줍니다.

2.9 parallelStream — 원리와 함정

parallelStream() 또는 .parallel() 을 붙이면 ForkJoinPool 공용 풀(commonPool) 에서 데이터를 쪼개 병렬 처리합니다.

소스 (1,000,000 개)
      │ Spliterator.trySplit() 로 반씩 분할 (재귀)
      ├─────────────┬─────────────┬─────────────┐
   250,000       250,000       250,000       250,000    ← 워커 스레드들이 각각 처리
      │             │             │             │
      └──── 부분 결과를 combiner 로 합침 (reduce / Collector.combiner) ────┘

• 공용 풀 크기 = CPU 코어 수 − 1 (+ 호출 스레드). 전체 JVM 이 하나의 풀을 공유합니다.
• 분할(split) 과 합치기(combine) 비용이 있으므로, 데이터가 작거나 요소당 작업이 가벼우면 순차보다 느립니다.

공유 상태 금지: 병렬 스트림 안에서 ArrayList.add 나 count++ 를 하면 02 레슨의 경쟁 조건이 그대로 발생합니다. 반드시 collect 로 결과를 모으세요. collect 는 각 스레드가 자기 컨테이너에 누적 후 combiner 로 합치므로 안전합니다.

순서: forEach 는 병렬에서 순서가 뒤섞입니다. 순서가 필요하면 forEachOrdered (병렬 이득 일부 포기). findFirst 는 순서를 지키느라 느리고, findAny 는 빠릅니다. toList() 는 병렬이어도 원래 순서를 유지합니다(인카운터 순서 보장 소스일 때).

커스텀 풀: I/O 가 섞이거나 공용 풀 오염을 피하려면 자기 풀에서 실행합니다.

ForkJoinPool pool = new ForkJoinPool(4);
long sum = pool.submit(() -> data.parallelStream().mapToLong(this::heavy).sum()).get();
pool.shutdown();

이는 문서화된 보장이 아닌 구현 동작(스트림이 호출 스레드의 풀을 사용)에 의존하지만 널리 쓰이는 관용구입니다. 진짜 I/O 병렬은 02 레슨의 가상 스레드가 정답입니다.

2.10 스트림 일회성과 부수효과 규칙

• 스트림은 한 번만 최종 연산할 수 있습니다. 두 번째 호출은 IllegalStateException: stream has already been operated upon or closed.
• 람다는 비간섭(non-interfering) 이어야 합니다: 파이프라인 도중 소스 컬렉션을 수정하면 ConcurrentModificationException 또는 미정의 동작.
• 람다는 무상태(stateless) 여야 합니다: 외부 변수에 의존한 결과가 실행 순서에 따라 달라지면 병렬에서 깨집니다.
• peek 은 디버깅용입니다. 최적화로 건너뛰어질 수 있습니다(예: count() 가 크기를 바로 알 수 있으면 파이프라인을 안 돌림).