Java 8 이전에는 컬렉션 처리를 병렬화하려면 수동으로 Thread 관리를 하거나 명시적으로 ExecutorService 제출을 해야 했고, 개발자는 작업 분할 및 동기화를 수동으로 처리해야 했습니다. Java 8에서 Stream API의 도입은 Spliterator 인터페이스를 통해 병렬성을 추상화하였으며, 이는 SIZED와 같은 특성을 사용하여 알려진 요소 수를 나타냅니다. 이 특성은 프레임워크가 균형 잡힌 이진 분할을 수행할 수 있게 하여 ForkJoinPool을 위한 최적의 작업 트리를 생성합니다.
Spliterator가 SIZED 특성이 부족할 경우(생성기 함수, Iterator 기반 스트림 또는 무한 시퀀스에서 일반적임), 프레임워크는 균형 잡힌 작업 트리를 생성하기 위해 이진 분할(2로 나누기)을 수행할 수 없습니다. 맹목적인 분할은 수백만 개의 작은 작업(세분화 폭주)을 생성하여 조정 오버헤드가 실행 시간을 지배하게 하거나, 과도하게 큰 청크를 생성하여 하나의 스레드가 대규모 백로그를 처리하는 동안 작업자 스레드를 유휴 상태로 남겨둡니다. 이 예측 불가능성은 fork-join 병렬성의 기본 가정을 깨트리는데, 그것은 작업이 대략 동일한 하위 작업으로 분할될 수 있다고 가정합니다.
프레임워크는 기본 IteratorSpliterator 구현을 통해 기하학적 배치를 사용합니다. 반으로 나누는 대신, 기하급수적으로 증가하는 배치 크기(1, 2, 4, 8, MAX_BATCH까지)를 사용하여 분할 비용을 분산시키면서 작업 생성은 로그 깊이로 제한합니다. ForkJoinPool은 경량 작업을 선호하는 작업 도둑질(work-stealing)을 사용하여 알려지지 않은 크기를 보완하고, AbstractTask는 전체 크기 정보 없이 완료 신호를 계산합니다. 정렬되지 않은 크기 미지정 스트림의 경우, 파이프라인은 분할 중 요소를 ArrayList에 버퍼링하여 만남 순서를 유지하며, 메모리와 병렬성 안전성을 trade-off 합니다.
텔레메트리 시스템은 Socket 연결을 통해 전송되는 실시간 센서 데이터를 처리합니다. 데이터는 JSON 객체의 연속 스트림으로 도착하며, 비즈니스 요구 사항은 이 객체들을 병렬로 파싱하고 필터링하여 저장 전 대기 시간을 최소화하는 것입니다. 문제는 데이터의 예측 불가능한 도착 속도와 총량입니다.
초기 구현은 InputStream을 BufferedReader로 감싸고 **lines().parallel()**을 사용했습니다. 그러나 성능 프로파일링 결과, 병렬 스트림의 성능이 지나치게 많은 작업 생성 오버헤드로 인해 순차 처리보다 훨씬 느린 것으로 드러났습니다. 근본적인 원인은 **BufferedReader.lines()**의 기본 Spliterator가 SIZED 특성을 가지고 있지 않아서, 처음에 Long.MAX_VALUE를 추정값으로 보고하여 프레임워크가 각 줄에 대한 마이크로 작업을 생성하게 합니다.
한 가지 접근 방식은 전체 스트림을 **ArrayList<String>**에 버퍼링한 후 병렬 처리하는 것이었습니다. 이렇게 하면 SIZED 특성이 제공되어 CPU 코어 간에 완벽한 이진 분할이 가능해집니다. 그러나 이는 전체 배치가 도착할 때까지 데이터를 처리할 수 없으므로 용납할 수 없는 지연이 발생하고, 매분 수백만 개의 이벤트를 처리할 때 심각한 메모리 압박을 유발하여 스트리밍 패러다임을 사실상 무효화했습니다.
또 다른 고려된 해결책은 기본 스트림과 관계없이 항상 정확히 1000줄의 고정 크기 청크로 분할하는 사용자 정의 Spliterator를 구현하는 것이었습니다. 이 방법은 예측 가능한 작업 크기를 제공했지만, 각 줄의 처리 시간이 크게 변동하는 경우 실패했습니다. 하나의 작업자가 1000개의 복잡한 객체를 받는 동안 다른 작업자는 1000개의 간단한 객체를 받을 수 있어, 심각한 부하 불균형과 유휴 CPU 코어가 가장 느린 작업을 기다리는 문제가 발생했습니다.
선택된 해결책은 표준 라이브러리의 기하학적 배치 전략을 모방한 사용자 정의 Spliterator를 구현하는 것이었습니다. 이는 초기 값을 1로 시작하여 각 성공적인 분할마다 두 배로 증가시키고 최대 1024까지 허용하여 프레임워크가 사전 지식 없이도 실제 스트림 길이에 적응할 수 있게 했습니다. 이 접근 방식은 초기 소규모 작업의 오버헤드를 스트림이 진행됨에 따라 더 큰 배치의 효율성과 균형을 이루었습니다.
기하학적 배치 접근 방식은 8코어 시스템에서 순차 처리 대비 3.5배의 속도 향상을 달성했습니다. 메모리 사용량은 스트림 지속 시간에 관계없이 일정하게 유지되었고, 지연 시간은 전체 자료화 완료를 기다리지 않고 즉시 처리가 시작되면서 낮게 유지되었습니다. 적응형 크기는 초기 구현에서 발생한 세분화 폭주를 방지했습니다.
병렬 스트림에서 동기화된 컬렉션을 감싸는 것이 CPU 집약적인 작업에 대해서도 순차적 동등물에 비해 성능을 저하시킬 수 있는 이유는 무엇입니까?
많은 후보자들은 **Collections.synchronizedList()**나 동기화된 Map 구현이 병렬 스트림에 안전하다고 가정합니다. 그러나 이러한 컬렉션의 Spliterator가 SIZED를 보고하더라도 각 접근의 동기화로 인해 거대한 캐시 일관성 트래픽이 발생합니다. 여러 ForkJoinPool 스레드가 각 요소에 대해 동일한 모니터에 대해 경합할 때, 동기화 비용과 컨텍스트 스위칭이 병렬 이익을 초월하게 됩니다. 올바른 접근 방식은 ConcurrentHashMap 또는 CopyOnWriteArrayList(쓰기 작업이 드물 경우)를 사용하거나, 소스 컬렉션이 개입하지 않고 스레드 안전한 Spliterator 특성인 CONCURRENT를 통해 접근하는 것을 요구합니다.
ORDERED 특성이 크기 미지정 스트림과 결합될 경우 최종 작업이 직렬화될 가능성이 있는 이유는 무엇이며, 왜 sorted()가 이를 악화시키는가?
후보자들은 종종 ORDERED가 SIZED가 없을 경우 프레임워크가 처리 완료 전 모든 요소를 버퍼링해야 한다는 사실을 놓칩니다. 특히 **sorted()**나 **distinct()**와 같은 상태 저장 작업을 위해서입니다. 총 크기를 알지 못하는 경우, 프레임워크는 **toArray()**를 위한 최종 배열이나 병합 정렬 버퍼를 미리 할당할 수 없습니다. 대신 요소들을 연결 리스트 또는 동적으로 크기가 조정되는 ArrayList에 축적하게 되어, 파이프라인 완료 단계가 사실상 직렬화됩니다. 이는 병렬 속도가 map/filter 단계로 제한되며, 최종 단계는 전체 데이터 세트를 기다리는 단일 스레드 병목 현상이 됩니다.
사용자 정의 Spliterator의 trySplit() 메서드가 부모와 다른 특성 집합을 보고하는 Spliterator를 반환하는 경우 발생하는 특정 계약 위반은 무엇입니까?
개발자가 **trySplit()**을 재정의하지만 특성 일관성을 유지하지 않을 경우 미묘한 오류가 발생합니다. Spliterator 계약은 반환된 spliterator가 정렬, 고유성 및 정렬 여부에 관한 동일한 특성을 가져야 한다고 요구합니다. 부모가 ORDERED를 보고하더라도 자식(분할 결과)이 그렇지 않으면, Stream 프레임워크의 최적화 과정에서 정렬 단계를 제거하거나 작업을 재정렬하여 잘못된 결과를 초래할 수 있습니다. 특성은 분할 간에 안정적이어야 하며, 파이프라인은 이러한 플래그를 기반으로 융합 최적화를 수행하기 때문에 일관되지 않은 플래그는 병렬 정확성을 위한 필수적인 발생 이전 관계를 깨트리게 됩니다.