Stream API

От чего зависит эффективность параллельного стрима при разбиении его источника?

Разберите ошибку в объявлении Collector: почему параллельный сбор может повредить результат, несмотря на наличие combiner?

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

Collector<Integer, List<Integer>, List<Integer>> bad = Collector.of(
    ArrayList::new,
    List::add,
    (left, right) -> { left.addAll(right); return left; },
    Collector.Characteristics.CONCURRENT
);

List<Integer> result = IntStream.range(0, 100_000)
    .parallel().unordered().boxed().collect(bad);

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

Как компилятор определяет тип лямбда-выражения, переданного операции Stream API?

Что произойдёт при повторном использовании одного объекта Stream после завершения терминальной операции?

В сервисе собирают числа из параллельного стрима в строку. Определите, какой контракт нарушает этот код и почему результат может быть некорректным.

String result = IntStream.rangeClosed(1, 1000)
    .parallel()
    .boxed()
    .reduce(
        new StringBuilder(),
        (builder, value) -> builder.append(value).append(','),
        (left, right) -> left.append(right)
    )
    .toString();

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

Объясните механизм, из-за которого промежуточная операция Stream не обрабатывает элементы сразу после своего вызова.

При параллельном сборе один и тот же Collector получает несколько частичных контейнеров: чем определяется их корректное объединение?

В практической ситуации параллельный стрим добавляет элементы во внешний ArrayList через forEach. Какой механизм делает результат ненадёжным?