Чому filter () після flatMap () "не зовсім" ледачий у потоках Java?

Question 1

У мене є такий зразок коду:

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()
);

Вихід такий:

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

Звідси я бачу, що в першому випадку streamсправді поводиться ліниво - ми використовуємо, findFirst()тому, коли у нас є перший елемент, наша фільтруюча лямбда не викликається. Однак у другому випадку, який використовує flatMaps, ми бачимо, що незважаючи на перший елемент, який відповідає умові фільтра, знайдений (це просто будь-який перший елемент, оскільки лямбда завжди повертає істину), подальший вміст потоку все ще надходить через функцію фільтрації.

Я намагаюся зрозуміти, чому він поводиться так, а не здається після обчислення першого елемента, як у першому випадку. Будемо вдячні за будь-яку корисну інформацію.

Question 2

TL; DR, це було розглянуто в JDK-8075939 та виправлено в Java 10 (і повернуто до Java 8 у JDK-8225328 ).

Розглядаючи реалізацію ( ReferencePipeline.java), ми бачимо метод [ посилання ]

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

який буде викликаний для findFirstроботи. Особливе, про що слід подбати, це те, sink.cancellationRequested()що дозволяє закінчити цикл на першому матчі. Порівняти із [ посиланням ]

@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);
                    }
                }
            };
        }
    };
}

Метод просування одного елемента закінчується викликом forEachпідпотоку без можливості попереднього завершення, а коментар на початку flatMapметоду навіть розповідає про цю відсутність функції.

Оскільки це більше, ніж просто оптимізація, оскільки це передбачає, що код просто ламається, коли підпотік нескінченний, я сподіваюся, що розробники незабаром докажуть, що вони "можуть зробити краще, ніж це" ...

Для ілюстрації наслідків, хоч і Stream.iterate(0, i->i+1).findFirst()працює, як очікувалося, Stream.of("").flatMap(x->Stream.iterate(0, i->i+1)).findFirst()опиниться в нескінченному циклі.

Що стосується специфікації, більшу частину її можна знайти в

розділ "Потокові операції та трубопроводи" специфікації пакету :

...

Проміжні операції повертають новий потік. Вони завжди ліниві ;

...

... Лінощі також дозволяють уникати вивчення всіх даних, коли це не потрібно; для таких операцій, як "знайти перший рядок довшим за 1000 символів", необхідно лише вивчити достатньо рядків, щоб знайти той, який має бажані характеристики, не вивчаючи всі рядки, доступні з джерела. (Ця поведінка стає ще важливішою, коли вхідний потік нескінченний і не просто великий.)

...

Крім того, деякі операції вважаються операціями короткого замикання . Проміжна операція є коротким замиканням, якщо, подавшись з нескінченним входом, вона може в результаті створити кінцевий потік. Операція терміналу є короткозамкненою, якщо, якщо вона представлена з нескінченним входом, вона може закінчитися за скінченний час. Операція короткого замикання в трубопроводі є необхідною, але недостатньою умовою для того, щоб обробка нескінченного потоку нормально закінчувалася за скінчений час.

Зрозуміло, що операція короткого замикання не гарантує кінцевого припинення часу, наприклад, коли фільтр не відповідає жодному елементу, який обробка не може завершити, але реалізація, яка не підтримує жодного припинення в обмежений час, просто ігноруючи короткозамкнений характер операції далеко не відповідає специфікації.

Question 3

Елементи вхідного потоку ліниво споживаються один за одним. Перший елемент, 1перетворюється двома flatMaps в потік -1, 0, 1, 0, 1, 2, 1, 2, 3, так що весь потік відповідає лише першому вхідному елементу. Вкладені потоки охоче матеріалізуються трубопроводом, потім сплющуються, потім подаються на filterсцену. Це пояснює ваш результат.

Вищезазначене не випливає з фундаментальних обмежень, але, мабуть, це значно ускладнило б отримання повноцінної ліні для вкладених потоків. Я підозрюю, що зробити ще ефективнішим буде ще більший виклик.

Для порівняння, ледачі послідовники Clojure отримують ще один шар обгортання для кожного такого рівня вкладеності. Завдяки такій конструкції операції можуть навіть провалитися, StackOverflowErrorколи вкладання здійснюється до крайньої міри.

Question 4

Що стосується обриву з нескінченними підпотоками, поведінка flatMap стає ще більш дивовижним, коли вводиться проміжна (на відміну від термінальної) операція короткого замикання.

Поки наступне працює, як очікувалося, роздруковує нескінченну послідовність цілих чисел

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

наступний код друкує лише "1", але все одно не закінчується:

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

Я не можу собі уявити прочитання специфікації, в якій це не було помилкою.

Question 5

У своїй безкоштовній бібліотеці StreamEx я представив колектори короткого замикання. При збиранні послідовного потоку з короткозамкненим колектором (як MoreCollectors.first()) рівно один елемент споживається від джерела. Внутрішньо це реалізовано досить брудно: використання спеціального винятку для розриву потоку управління. Використовуючи мою бібліотеку, ваш зразок можна переписати таким чином:

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()
        );

Результат такий:

-1
Result: -1

Question 6

На жаль .flatMap(), не лінується. Однак flatMapтут доступний спеціальний обхідний шлях: чому .flatMap () настільки неефективний (не ледачий) у Java 8 та Java 9

Question 7

Я згоден з іншими людьми, що це помилка, відкрита на JDK-8075939 . І оскільки це все ще не виправлено більше ніж через рік. Я хотів би порекомендувати вам: 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

Розкриття інформації: Я розробник AbacusUtil.

Question 8

Сьогодні я теж натрапив на цю помилку. Поведінка не така затяжна, тому що простий випадок, як показано нижче, працює нормально, але подібний виробничий код не працює.

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

Для хлопців, котрі не можуть чекати ще пару років для переходу на JDK-10, існує альтернативний справжній ледачий потік. Він не підтримує паралельність. Він був призначений для перекладу JavaScript, але у мене це вийшло, оскільки інтерфейс той самий.

StreamHelper базується на колекції, але легко адаптувати Spliterator.

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