🟢 Junior Level

Стрими спроектовані у стилі функціонального програмування. Це означає:

1. Операції не повинні змінювати зовнішній стан (no side effects)
2. Результат залежить тільки від вхідних даних (deterministic)
3. Одну й ту саму операцію можна викликати двічі з тим самим результатом (idempotent)

Чому побічні ефекти — це погано:

1. Непередбачуваність: Результат залежить від порядку виконання, який у паралельних стримах випадковий
2. Важко тестувати: Тести можуть проходити іноді, а іноді ні (“flaky tests”)
3. Важко читати: Незрозуміло, що робить код

// ПОГАНО — побічний ефект
List<String> result = new ArrayList<>();
stream.forEach(result::add);

// ДОБРЕ — чиста операція
List<String> result = stream.collect(Collectors.toList());

Правило: використовуйте forEach з побічним ефектом ТІЛЬКИ якщо дія необоротна та одноразова (відправка email, запис у лог). Якщо результат можна обчислити — використовуйте collect/reduce.

🟡 Middle Level

Принцип Non-interference

Функції в стримах не повинні змінювати джерело даних стрима:

• Якщо модифікуєте колекцію під час стрима → ConcurrentModificationException
• Стрими використовують Spliterator з “структурною перевіркою” джерела

Проблеми в паралельних стримах

1. Непередбачуваний порядок: Логіка, що залежить від порядку, руйнується
2. Видимість пам’яті: Зміни в одному потоці можуть бути не видимі в іншому без синхронізації
3. Оптимізації JIT: JIT може переставляти операції — побічні ефекти роблять це небезпечним

Коли побічні ефекти легітимні

Тільки два випадки:

• forEach(): Коли реально потрібно відправити результат “у зовнішній світ”
• peek(): Виключно для налагодження. Ніколи не використовуйте для бізнес-логіки!

🔴 Senior Level

The Atomic Reference Trap

AtomicInteger для підрахунку всередині паралельного стрима:

• Проблема 1 (Продуктивність): 100 потоків, contention за кеш-лінію → стрим повільніший за for
• Проблема 2 (Архітектура): Втрачаєте можливість рефакторингу. Чиста функція reduce/collect дозволяє JVM вирішувати, як об’єднувати результати

JIT Optimization Impact

JIT-компілятор переставляє операції в стримі, якщо вважає, що вони не впливають на результат. Побічні ефекти роблять такі оптимізації небезпечними — код поводиться по-різному з різними прапорцями JVM.

Transactional Side Effects

repo.save() всередині forEach паралельного стрима:

• Некеровані транзакції
• Неможливість rollback
• Вичерпання пулу з’єднань

Діагностика

• Checkstyle/Sonar: Налаштуйте правила, що забороняють мутацію зовнішніх об’єктів всередині стримів
• Functional Style: Якщо потрібен стан — використовуйте collect() з кастомним акумулятором. Це “легальний” спосіб

---

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

• Стрими спроектовані у стилі функціонального програмування: no side effects, deterministic, idempotent
• Принцип Non-interference: функції в стримах не повинні змінювати джерело даних — інакше ConcurrentModificationException
• Побічні ефекти в паралельних стримах: непередбачуваний порядок, visibility issues, JIT-оптимізації стають небезпечними
• Легітимні побічні ефекти: тільки forEach() (вивід «у зовнішній світ») і peek() (виключно налагодження)
• JIT-компілятор переставляє операції; побічні ефекти роблять такі оптимізації небезпечними — код поводиться по-різному з різними прапорцями JVM
• repo.save() всередині forEach паралельного стрима: некеровані транзакції, неможливість rollback, вичерпання пулу з’єднань
• Правило: forEach з побічним ефектом ТІЛЬКИ якщо дія необоротна та одноразова (email, лог)

Часті уточнюючі запитання:

• Чому JIT-оптимізації конфліктують з side effects? — JIT переставляє/елімінує операції, припускаючи чистоту функцій; side effects ламають це припущення
• Що робити, якщо потрібен стан всередині стрима? — Використовувати collect() з кастомним акумулятором — це «легальний» спосіб
• Коли побічний ефект у forEach виправданий? — Відправка email, запис у лог, push-нотифікація — необоротні одноразові дії
• Як заборонити побічні ефекти на рівні команди? — Checkstyle/Sonar: правила, що забороняють мутацію зовнішніх об’єктів всередині стримів

Червоні прапорці (НЕ говорити):

• «peek() можна використовувати для бізнес-логіки» — ніколи; він для налагодження і може бути пропущений JVM
• «Якщо працює на sequentialStream, значить безпечно» — паралельний режим проявить race conditions
• «AtomicInteger вирішує проблему thread-safety» — вирішує, але contention вбиває продуктивність
• «Побічні ефекти — це просто стиль коду» — це архітектурна проблема: тестованість, детермінізм, JIT-safety

Пов’язані теми:

• [[Що таке побічні ефекти (side effects) в Stream]]
• [[Чи можна змінювати стан зовнішніх змінних в Stream операціях]]
• [[Які потенційні проблеми можуть бути з паралельними стримами]]
• [[В чому різниця між reduce() та collect()]]