Java Streams에서 `FlatMap()` 이후 `filter()`가 지연되지 않는 것처럼 보이는 이유는 무엇입니까?

Java 스트림에서 flatMap() 이후 filter()가 "완전히" 지연되지 않는 이유는 무엇입니까?

Java 8 스트림에서 다음과 같은 중간 작업은 다음과 같습니다. filter() 및 flatMap()은 게으르다. 즉, findFirst()와 같은 터미널 작업이 호출될 때까지 실행되지 않습니다. 그러나 filter()가 flatMap() 뒤에 오면 이러한 게으름이 완전히 실현되지 않아 예상치 못한 동작이 발생합니다.

다음 코드 예제를 고려하세요.

Stream.of(1, 2, 3)
        .filter(i -> {
            System.out.println(i);
            return true;
        })
        .findFirst()
        .get();

출력에서는 첫 번째 조건이 충족되면 filter()가 게으르고 단락됨을 나타내는 요소가 인쇄됩니다. 대조적으로:

Stream.of(1, 2, 3)
        .flatMap(i -> Stream.of(i - 1, i, i + 1))
        .flatMap(i -> Stream.of(i - 1, i, i + 1))
        .filter(i -> {
            System.out.println(i);
            return true;
        })
        .findFirst()
        .get();

놀랍게도 모든 요소가 인쇄됩니다. filter()는 조건을 즉시 충족하더라도 스트림의 후속 요소를 계속 처리합니다.

이유

이 동작은 Java Streams 구현으로 인한 것입니다. flatMap() 이후에는 스트림에 더 이상 원래 요소가 포함되지 않습니다. 대신, flatMap()에 의해 생성된 일련의 평면화된 요소를 포함합니다. filter()가 뒤따를 때 원래 스트림이 아닌 이러한 평면화된 요소에서 작동합니다.

findFirst()에서 사용되는 forEachWithCancel()의 구현은 싱크가 발생할 때까지 분할기에서 tryAdvance()를 계속 호출합니다. 취소를 요청하거나 분할기가 소진되었습니다. flatMap()의 경우 filter()가 이미 일치하는 항목을 찾은 경우에도 분할기가 조기 종료 가능성 없이 계속 진행됩니다.

Fix

이 문제는 Java 10에서 해결되었으며 Java 8로 백포트되었습니다. 이제 구현에서는 filter()와 같은 단락 작업이 다음과 같은 경우 flatMap()에서 조기 종료를 허용합니다.

결론

물론 flatMap() 이후에 filter()가 게으르지 않은 것처럼 동작하는 이유는 혼란스러울 수 있습니다. 기본 Java Streams 구현은 이 동작을 지시하며, 이는 나중에 Java 10에서 해결되고 Java 8로 백포트되었습니다. 이러한 이해는 이러한 시나리오를 효율적으로 처리하는 데 중요합니다.

위 내용은 Java Streams에서 `FlatMap()` 이후 `filter()`가 지연되지 않는 것처럼 보이는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!