🟢 Junior Level

Технически — можно, но категорически не рекомендуется.

Java требует, чтобы переменные в лямбдах были final или effectively final:

// НЕ СКОМПИЛИРУЕТСЯ
int sum = 0;
list.stream().forEach(n -> sum += n); // ошибка: sum должна быть final

// МОЖНО с AtomicInteger
AtomicInteger sum = new AtomicInteger(0);
list.stream().forEach(n -> sum.addAndGet(n)); // компилируется, но плохо

Правильный подход: Используйте reduce() или collect():

int sum = list.stream().mapToInt(Integer::intValue).sum();

🟡 Middle Level

Ограничение “Effectively Final”

Лямбда захватывает значение переменной (копирует в скрытое поле), а не ссылку на стек. Если переменная меняется в основном потоке, копия внутри лямбды устаревает.

Зачем это ограничение: лямбда может выполниться позже, когда метод уже завершился и его стек-фрейм уничтожен. Копирование гарантирует, что данные будут живы.

Почему это антипаттерн

1. Нарушение функциональной чистоты Стримы спроектированы в парадигме функционального программирования. Операции должны быть чистыми функциями.

2. Крах параллелизма В параллельных стримах изменение общей переменной приводит к:

• Race Conditions: Несколько потоков читают и пишут одновременно
• Visibility Issues: Изменения в L1-кэше одного потока не видны другому
• Синхронизация: Atomic или synchronized убивают смысл параллелизма

Примеры

// ПЛОХО — Side Effect
List<Integer> result = new ArrayList<>();
stream.filter(x -> x > 10).forEach(result::add);

// ХОРОШО — Reduction
List<Integer> result = stream.filter(x -> x > 10).collect(Collectors.toList());

🔴 Senior Level

Contention на Atomic

Если 100 потоков параллельного стрима инкрементируют один AtomicInteger, они конфликтуют на шине памяти (CAS loop) — стрим может стать в ~10 раз медленнее обычного цикла for (по данным JMH на 8-ядерном CPU при 1M элементов и AtomicInteger contention). Ваша цифра зависит от JVM и нагрузки.

GC Pressure

Создание мутабельных “оберток” для обхода final ограничений создает лишний мусор в куче.

Edge Cases

• AtomicInteger как счетчик: Результат непредсказуем в параллельном стриме (индексы будут вразнобой)
• Сборка в Map через forEach: Риск ConcurrentModificationException. Если ключи уникальны — toMap(). Если ключи могут повторяться — groupingBy() (иначе toMap бросит IllegalStateException: Duplicate key).

Диагностика

Static Analysis: SonarQube правило “Stream operations should be side-effect free” находит такие места.

Rule of Thumb: Если нужно изменить внешнюю переменную внутри стрима — вы выбрали неправильную terminal операцию. Посмотрите на reduce() или collect().

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Переменные в лямбдах должны быть final или effectively final — лямбда захватывает копию значения, а не ссылку
• AtomicInteger компилируется, но в параллельном стриме создаёт contention (CAS loop на шине памяти) — стрим может быть в ~10 раз медленнее
• Изменение внешних переменных нарушает парадигму функционального программирования, на которой построены стримы
• В параллельных стримах мутация общих переменных ведёт к race conditions, visibility issues, потере данных
• Правильный подход: reduce(), collect(), sum() — они инкапсулируют аккумуляцию
• Для Map-сборки с повторяющимися ключами используйте groupingBy(), а не toMap() (иначе IllegalStateException: Duplicate key)
• SonarQube находит такие места правилом «Stream operations should be side-effect free»

Частые уточняющие вопросы:

• Почему лямбды требуют effectively final? — Лямбда может выполниться позже, когда стек-фрейм метода уничтожен; копия гарантирует живучесть данных
• Чем forEach(result::add) отличается от collect(toList())? — forEach мутирует внешний ArrayList (side effect), collect — чистая операция редукции
• Почему 100 потоков с AtomicInteger медленнее цикла for? — CAS loop на одной кэш-линии вызывает cache thrashing — потоки перечитывают одну и ту же линию памяти
• Какая terminal-операция заменяет мутацию списка? — filter(...).collect(Collectors.toList())

Красные флаги (НЕ говорить):

• «AtomicInteger — безопасный способ мутации в параллельном стриме» — он потокобезопасен, но contention убивает производительность
• «Можно менять переменную, если обернуть её в класс» — это обход компилятора, но проблема thread-safety остаётся
• «В обычном стриме мутация безопасна» — она компилируется, но нарушает функциональную парадигму и блокирует параллелизм
• «forEach — нормальный способ собрать результат» — это антипаттерн, используйте collect()

Связанные темы:

• [[Что такое побочные эффекты (side effects) в Stream]]
• [[Почему следует избегать побочных эффектов в Stream]]
• [[Что делает операция reduce()]]
• [[В чём разница между reduce() и collect()]]
• [[Какие потенциальные проблемы могут быть с параллельными стримами]]