Stream API

При использовании partitioningBy для потока без элементов одного класса гарантируется ли наличие обеих булевых ключей в результате?

В отчёте сумма значений выходит за диапазон int при использовании summingInt: почему результат может оказаться неверным?

В каком порядке выполняются несколько обработчиков, зарегистрированных у одного Stream через onClose?

В сервисе нужно сохранить все группы, даже если после условия в группе нет элементов. Почему в коде withDownstream содержит ключ a, а beforeGrouping — нет?

import java.util.*;
import java.util.stream.*;

List<String> words = List.of("ant", "ape", "bat", "bear");

Map<Character, List<String>> beforeGrouping = words.stream()
    .filter(s -> s.length() > 3)
    .collect(Collectors.groupingBy(s -> s.charAt(0)));

Map<Character, List<String>> withDownstream = words.stream()
    .collect(Collectors.groupingBy(
        s -> s.charAt(0),
        Collectors.filtering(s -> s.length() > 3, Collectors.toList())
    ));

При сборе Stream в Map функция слияния для повторяющегося ключа возвращает null: что произойдёт с этой записью?

Какое свойство поведения Stream нарушается, когда предикат изменяет общее состояние?

Для деления элементов по булеву условию какой коллектор точнее выражает задачу: partitioningBy или groupingBy?

В параллельном сборе Stream с нетривиальным Collector когда применяется finisher и почему его нельзя считать обработчиком каждого частичного результата?

В цепочке фильтрации один из предикатов объединён через Predicate.and: при каком результате первого предиката второй гарантированно не запускается?

При сборе упорядоченного стрима в Map порядок ключей при обходе результата меняется: каким механизмом это объясняется?

В ситуации, когда один стрим должен сформировать единый итог из двух независимых сборов, какой механизм Collectors.teeing позволяет сделать это за один проход?

При проектировании источника для параллельного стрима какую роль играет метод trySplit?

В чём механистическое отличие takeWhile от filter при обработке упорядоченного стрима?

Чтение файла через Stream<String> завершается терминальной операцией: почему стрим всё равно нужно явно закрыть?

Укажите результат применения flatMap, если функция преобразования вернула null для одного элемента.

Какой исполнитель по умолчанию обслуживает задачи параллельного Stream?

Каким механизмом операция anyMatch прекращает обработку стрима после нахождения подходящего элемента?

Способна ли параллельная обработка ускорить поток, если каждая лямбда блокируется на внешнем сервисе?

Какую гарантию обработки каждого элемента даёт побочный эффект, размещённый в peek?

Каким правилом Stream API определяется итоговый режим выполнения, если в одной цепочке несколько раз меняют последовательность на параллельную и обратно?