Tại sao filter () sau khi flatMap () "không hoàn toàn" lười biếng trong các luồng Java?

Tôi có mã mẫu sau:

System.out.println(
       "Result: " +
        Stream.of(1, 2, 3)
                .filter(i -> {
                    System.out.println(i);
                    return true;
                })
                .findFirst()
                .get()
);
System.out.println("-----------");
System.out.println(
       "Result: " +
        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()
);

Kết quả như sau:

1
Result: 1
-----------
-1
0
1
0
1
2
1
2
3
Result: -1

Từ đây, tôi thấy rằng trong trường hợp đầu tiên streamthực sự hoạt động một cách lười biếng - chúng tôi sử dụng findFirst()vì vậy khi chúng tôi có phần tử đầu tiên lambda lọc của chúng tôi không được gọi. Tuy nhiên, trong trường hợp thứ hai sử dụng flatMaps, chúng ta thấy rằng mặc dù phần tử đầu tiên đáp ứng điều kiện lọc được tìm thấy (nó chỉ là bất kỳ phần tử đầu tiên nào vì lambda luôn trả về true) các nội dung khác của luồng vẫn được cung cấp thông qua chức năng lọc.

Tôi đang cố gắng hiểu tại sao nó hoạt động như vậy thay vì từ bỏ sau khi phần tử đầu tiên được tính như trong trường hợp đầu tiên. Bất kỳ thông tin hữu ích sẽ được đánh giá cao.

TL; DR, điều này đã được giải quyết trong JDK-8075939 và được sửa trong Java 10 (và được hỗ trợ lại cho Java 8 trong JDK-8225328 ).

Khi xem xét triển khai ( ReferencePipeline.java), chúng tôi thấy phương thức [ link ]

@Override
final void forEachWithCancel(Spliterator<P_OUT> spliterator, Sink<P_OUT> sink) {
    do { } while (!sink.cancellationRequested() && spliterator.tryAdvance(sink));
}

sẽ được gọi cho findFirsthoạt động. Điều đặc biệt cần quan tâm là sink.cancellationRequested()cho phép kết thúc vòng lặp ở trận đấu đầu tiên. So sánh với [ liên kết ]

@Override
public final <R> Stream<R> flatMap(Function<? super P_OUT, ? extends Stream<? extends R>> mapper) {
    Objects.requireNonNull(mapper);
    // We can do better than this, by polling cancellationRequested when stream is infinite
    return new StatelessOp<P_OUT, R>(this, StreamShape.REFERENCE,
                                 StreamOpFlag.NOT_SORTED | StreamOpFlag.NOT_DISTINCT | StreamOpFlag.NOT_SIZED) {
        @Override
        Sink<P_OUT> opWrapSink(int flags, Sink<R> sink) {
            return new Sink.ChainedReference<P_OUT, R>(sink) {
                @Override
                public void begin(long size) {
                    downstream.begin(-1);
                }

                @Override
                public void accept(P_OUT u) {
                    try (Stream<? extends R> result = mapper.apply(u)) {
                        // We can do better that this too; optimize for depth=0 case and just grab spliterator and forEach it
                        if (result != null)
                            result.sequential().forEach(downstream);
                    }
                }
            };
        }
    };
}

Phương thức tiến một mục sẽ kết thúc cuộc gọi forEachtrên luồng phụ mà không có bất kỳ khả năng kết thúc sớm hơn và chú thích ở đầu flatMapphương thức thậm chí còn cho biết về tính năng vắng mặt này.

Vì đây không chỉ là một thứ tối ưu hóa vì nó ngụ ý rằng mã chỉ đơn giản bị hỏng khi luồng phụ là vô hạn, tôi hy vọng rằng các nhà phát triển sớm chứng minh rằng họ “có thể làm tốt hơn điều này”…

Để minh họa các hàm ý, trong khi Stream.iterate(0, i->i+1).findFirst()hoạt động như mong đợi, Stream.of("").flatMap(x->Stream.iterate(0, i->i+1)).findFirst()sẽ kết thúc trong một vòng lặp vô hạn.

Về đặc điểm kỹ thuật, hầu hết nó có thể được tìm thấy trong

chương “Hoạt động dòng và đường ống” của đặc điểm kỹ thuật gói :

…

Các hoạt động trung gian trả về một luồng mới. Họ luôn lười biếng ;

…

… Sự lười biếng cũng cho phép tránh kiểm tra tất cả dữ liệu khi không cần thiết; đối với các hoạt động như "tìm chuỗi đầu tiên dài hơn 1000 ký tự", chỉ cần kiểm tra vừa đủ các chuỗi để tìm một chuỗi có các đặc điểm mong muốn mà không cần kiểm tra tất cả các chuỗi có sẵn từ nguồn. (Hành vi này thậm chí còn trở nên quan trọng hơn khi luồng đầu vào là vô hạn và không chỉ lớn.)

…

Hơn nữa, một số hoạt động được coi là hoạt động đoản mạch . Một hoạt động trung gian là ngắn mạch nếu, khi được trình bày với đầu vào vô hạn, kết quả là nó có thể tạo ra một dòng hữu hạn. Hoạt động của thiết bị đầu cuối bị chập mạch nếu, khi xuất hiện với đầu vào vô hạn, nó có thể kết thúc trong thời gian hữu hạn. Việc xảy ra hiện tượng đoản mạch trong đường ống là điều kiện cần nhưng chưa đủ để quá trình xử lý dòng vô hạn kết thúc bình thường trong thời gian hữu hạn.

Rõ ràng là hoạt động đoản mạch không đảm bảo chấm dứt thời gian hữu hạn, ví dụ: khi bộ lọc không khớp với bất kỳ mục nào, quá trình xử lý không thể hoàn thành, nhưng việc triển khai không hỗ trợ bất kỳ chấm dứt nào trong thời gian hữu hạn bằng cách bỏ qua bản chất đoản mạch của một hoạt động khác xa với thông số kỹ thuật.

Từng phần tử của luồng đầu vào được tiêu thụ một cách lười biếng. Phần tử đầu tiên 1, được chuyển đổi bởi hai flatMaps thành luồng -1, 0, 1, 0, 1, 2, 1, 2, 3, do đó toàn bộ luồng chỉ tương ứng với phần tử đầu vào đầu tiên. Các dòng lồng nhau được háo hức thực hiện bằng đường ống, sau đó được làm phẳng, sau đó được cung cấp cho filtersân khấu. Điều này giải thích đầu ra của bạn.

Những điều trên không xuất phát từ một hạn chế cơ bản, nhưng nó có thể sẽ khiến mọi thứ trở nên phức tạp hơn nhiều khi có được sự lười biếng hoàn toàn cho các luồng lồng nhau. Tôi nghĩ rằng nó sẽ là một thách thức lớn hơn để làm cho nó hoạt động hiệu quả.

Để so sánh, các seq lười biếng của Clojure nhận được một lớp bao bọc khác cho mỗi cấp độ lồng như vậy. Do thiết kế này, các hoạt động thậm chí có thể thất bại vớiStackOverflowError khi thực hiện lồng ghép ở mức quá cao.

Liên quan đến sự cố với các luồng phụ vô hạn, hành vi của flatMap vẫn trở nên đáng ngạc nhiên hơn khi một người ném vào hoạt động đoản mạch trung gian (trái ngược với thiết bị đầu cuối).

Trong khi phần sau hoạt động như mong đợi, in ra chuỗi số nguyên vô hạn

Stream.of("x").flatMap(_x -> Stream.iterate(1, i -> i + 1)).forEach(System.out::println);

mã sau chỉ in ra "1", nhưng vẫn không kết thúc:

Stream.of("x").flatMap(_x -> Stream.iterate(1, i -> i + 1)).limit(1).forEach(System.out::println);

Tôi không thể tưởng tượng việc đọc các thông số kỹ thuật mà không phải là một lỗi.

Trong thư viện StreamEx miễn phí của mình, tôi đã giới thiệu các bộ thu gom chập mạch. Khi thu thập dòng tuần tự với bộ thu ngắn mạch (như MoreCollectors.first()) chính xác một phần tử được tiêu thụ từ nguồn. Bên trong nó được triển khai theo một cách khá bẩn: sử dụng một ngoại lệ tùy chỉnh để phá vỡ luồng điều khiển. Sử dụng thư viện của tôi, mẫu của bạn có thể được viết lại theo cách này:

System.out.println(
        "Result: " +
                StreamEx.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;
                })
                .collect(MoreCollectors.first())
                .get()
        );

Kết quả là như sau:

-1
Result: -1

Thật không may .flatMap()là không lười biếng. Tuy nhiên, một flatMapgiải pháp tùy chỉnh có sẵn tại đây: Tại sao .flatMap () quá kém hiệu quả (không lười biếng) trong java 8 và java 9

Tôi đồng ý với những người khác, đây là một lỗi được mở tại JDK-8075939 . Và vì nó vẫn chưa được sửa sau hơn một năm. Tôi muốn giới thiệu cho bạn: AbacusUtil

N.println("Result: " + Stream.of(1, 2, 3).peek(N::println).first().get());

N.println("-----------");

N.println("Result: " + Stream.of(1, 2, 3)
                        .flatMap(i -> Stream.of(i - 1, i, i + 1))
                        .flatMap(i -> Stream.of(i - 1, i, i + 1))
                        .peek(N::println).first().get());

// output:
// 1
// Result: 1
// -----------
// -1
// Result: -1

Tiết lộ ： Tôi là nhà phát triển của AbacusUtil.

Hôm nay tôi cũng tình cờ gặp lỗi này. Hành vi không quá căng thẳng, vì trường hợp đơn giản, như bên dưới, đang hoạt động tốt, nhưng mã sản xuất tương tự không hoạt động.

 stream(spliterator).map(o -> o).flatMap(Stream::of).flatMap(Stream::of).findAny()

Đối với những người không thể đợi vài năm nữa để chuyển sang JDK-10, có một luồng lười thực sự thay thế. Nó không hỗ trợ song song. Nó được dành riêng cho bản dịch JavaScript, nhưng nó hoạt động với tôi, vì giao diện giống nhau.

StreamHelper dựa trên bộ sưu tập, nhưng nó rất dễ dàng để điều chỉnh Spliterator.

https://github.com/yaitskov/j4ts/blob/stream/src/main/java/javaemul/internal/stream/StreamHelper.java