🟢 Junior Level

Побочный эффект (side effect) — это любое действие внутри стрима, которое изменяет что-то за пределами самого стрима.

Примеры побочных эффектов:

• Изменение внешних переменных
• Печать в консоль (System.out.println)
• Запись в файл или базу данных
• Изменение объектов внутри стрима

// Побочный эффект — изменение внешней переменной
List<String> result = new ArrayList<>();
stream.forEach(result::add);

// Побочный эффект — вывод в консоль
stream.peek(System.out::println).collect(toList());

Побочные эффекты делают код непредсказуемым, особенно в параллельных стримах.

🟡 Middle Level

Что считается побочным эффектом

1. Изменение значений внешних переменных (мутация объектов в куче)
2. Выполнение I/O операций (печать, запись в файл, сетевой запрос)
3. Изменение состояния элементов внутри стрима

Три принципа безопасного стрима

Для корректной работы (особенно параллельной) функции должны быть:

1. Identity: Начальное значение не должно менять результат
2. Associativity: Порядок группировки не влияет на результат
3. Non-interference: Источник данных не должен изменяться во время выполнения стрима

Опасности

Непредсказуемость: В параллельном стриме побочные эффекты выполняются в случайном порядке.

Снижение производительности: Побочные эффекты требуют синхронизации — потоки выстраиваются в очередь.

Легитимные побочные эффекты

Только в двух местах:

• forEach(): Terminal операция для действий “в мир”
• peek(): Только для отладки (логирование промежуточных состояний)

🔴 Senior Level

The Atomic Reference Trap

AtomicInteger для подсчета внутри forEach параллельного стрима:

• 100 потоков пишут в одну кэш-линию (cache line — блок памяти 64 байта, который CPU загружает целиком). Два потока, пишущие в соседние байты, заставляют CPU постоянно перечитывать одну и ту же линию (cache thrashing).
• Стрим медленнее обычного цикла for

Transactional Side Effects

В большинстве случаев не делайте repo.save() внутри map или forEach параллельного стрима. Исключение: batch-обработка, где каждая запись в БД независима и вы контролируете транзакции вручную.

Logging Overhead

stream.peek(log::info) в Highload может замедлить обработку в 100 раз из-за блокировок внутри логгера.

Edge Cases

Missing Side Effects: Если используете peek() для бизнес-логики — в Java 9+ при terminal операции count() на источниках с характеристикой SIZED (ArrayList, массив) — JVM оптимизирует count() и пропускает весь пайплайн. На не-SIZED источниках (LinkedList, Stream.generate()) — peek() выполнится.

Deadlock Potential: Побочный эффект, захватывающий блокировку, может привести к дедлоку с другим потоком ForkJoinPool.

Диагностика

Всегда тестируйте стримы с побочными эффектами на parallelStream(). Если результаты “плавают” — баг в дизайне.

---

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

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

• Побочный эффект — любое действие внутри стрима, изменяющее что-то за его пределами (мутация переменных, I/O, печать)
• Побочные эффекты делают параллельные стримы непредсказуемыми: порядок выполнения случайный
• Три принципа безопасного стрима: Identity (нейтральный элемент), Associativity (порядок группировки не важен), Non-interference (источник не меняется)
• Легитимные побочные эффекты только в двух местах: forEach() (terminal) и peek() (отладка)
• AtomicInteger в forEach параллельного стрима: cache line contention — стрим медленнее обычного цикла for
• В Java 9+ peek() может не выполниться на SIZED источниках с count() — JVM оптимизирует пайплайн
• stream.peek(log::info) в Highload замедляет обработку до 100x из-за блокировок логгера

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

• Что считается побочным эффектом? — Мутация внешних переменных, I/O, изменение состояния объектов внутри стрима
• Можно ли использовать peek() для бизнес-логики? — Категорически нет; в Java 9+ он может не выполниться на SIZED источниках с count()
• Что такое Non-interference? — Источник данных стрима не должен изменяться во время выполнения пайплайна, иначе ConcurrentModificationException
• Когда side effect допустим в forEach? — Когда действие необратимо и однократно: отправка email, запись в лог

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

• «peek() — нормальное место для бизнес-логики» — он может не выполниться; для production используйте map()
• «AtomicInteger — решение всех проблем параллелизма» — contention на CAS убивает производительность
• «Побочные эффекты безопасны в обычном стриме» — они блокируют будущий параллелизм и нарушают функциональную парадигму
• repo.save() внутри map параллельного стрима — это нормально» — неуправляемые транзакции, нет rollback, исчерпание пула соединений

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

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