Java for Beginner

forEach: последнее средство, не первое

Метод forEach предназначен для конечных действий (terminal side effects), не для агрегации данных. Его корректное применение — операции, которые по своей природе требуют побочных эффектов и уже учитывают многопоточность:

// Корректное использование: логирование
orders.stream()
    .filter(Order::isUrgent)
    .forEach(o -> logger.info("Срочный заказ: {}", o.getId()));

// Корректное использование: запись в потокобезопасный sink
processedItems.parallelStream()
    .forEach(database::save);  // database.save потокобезопасен

// Корректное использование: отправка сообщений в брокер
events.stream()
    .forEach(kafkaTemplate::send);

В этих случаях побочный эффект — сама цель операции. Мы не накапливаем данные для дальнейшей обработки, а выполняем окончательное действие над каждым элементом.
collect: правильный путь агрегации

Для накопления результатов Stream API предоставляет collect — мощную и гибкую терминальную операцию, инкапсулирующую стратегию свёртки потока в конкретную структуру данных.

// Правильно: агрегация через collect
List<String> names = users.stream()
    .filter(User::isActive)
    .map(User::getName)           // Чистая трансформация
    .collect(Collectors.toList()); // Инкапсулированная мутация внутри коллектора

Здесь мутация происходит внутри Collector, не видима снаружи, потокобезопасна при параллельном выполнении (через механизм комбайнеров), композиционна — результат можно передать дальше.

Как работает безопасность collect в параллельном потоке:

List<String> names = users.parallelStream()
    .filter(User::isActive)
    .map(User::getName)
    .collect(Collectors.toList());  // Корректно при parallel!

Коллектор toList() использует стратегию "разделяй и властвуй": поток делится на сегменты, каждый обрабатывается в своём потоке с локальным ArrayList (аккумулятор), затем локальные списки комбинируются в один результат. Никакой совместной мутации, никаких блокировок — только локальные изменения и финальное слияние.

Мутация внутри map и filter: скрытая бомба

Побочные эффекты опасны не только в forEach.

Любая промежуточная операция с мутацией внешнего состояния создаёт непредсказуемое поведение:

// Антипаттерн: мутация в map
AtomicInteger counter = new AtomicInteger(0);
List<Integer> numbered = items.stream()
    .map(item -> {
        int num = counter.incrementAndGet();  // Побочный эффект!
        return num + ": " + item;
    })
    .collect(toList());

// При parallelStream() нумерация будет хаотичной и пропущенной

Здесь map используется не для преобразования элемента, а для генерации глобального счётчика. Это нарушает чистоту функции: результат зависит не только от входа, но от внешнего состояния и порядка выполнения.

Решение — встроить нумерацию в структуру данных или использовать специализированные операции:

// Правильно: явная нумерация через индекс
List<String> numbered = IntStream.range(0, items.size())
    .mapToObj(i -> (i + 1) + ": " + items.get(i))
    .collect(toList());

// Или через StreamUtils сторонних библиотек с zipWithIndex

Идентификация побочных эффектов

Признаки, что код содержит опасные побочные эффекты:
- Лямбда не возвращает значение, но делает что-то "полезное": x -> list.add(x), x -> map.put(x.getKey(), x)
- Захват изменяемых внешних переменных: лямбда использует переменные, объявленные до неё, и вызывает на них модифицирующие методы
- Необходимость очистки состояния между запусками: тесты требуют list.clear() или создания новых объектов
- Недетерминированные результаты при параллельном выполнении: одинаковый вход даёт разный выход
- Рефакторинг от побочных эффектов к чистым функциям следует шаблону: вынести мутацию в collect, преобразования в map, фильтрацию в filter, а forEach оставить только для истинно терминальных действий.

#Java #для_новичков #beginner #stream_api #side_effects

🔥3👍2

130 views08:59