Parallel streams — это не «бесплатный» прирост производительности, а дорогая оптимизация.

🟣 Любое распараллеливание добавляет накладные расходы: разбиение данных, управление задачами через fork-join, синхронизацию и объединение результатов. Если операция над элементом дешёвая или данных недостаточно много, этот оверхед полностью съедает потенциальный выигрыш — и последовательный стрим оказывается быстрее.

🟣 Вторая причина — ограничения самой задачи. Многие вычисления по природе последовательны или содержат существенную последовательную часть, которую нельзя распараллелить. Закон Амдала жёстко ограничивает максимальный speedup: даже небольшой последовательный участок ставит потолок ускорению, независимо от количества ядер. В streams эта доля часто больше, чем кажется.

🟣 Наконец, упор часто происходит не в CPU, а в память. Параллельные стримы хорошо работают на больших массивах, но быстро деградируют на графах, списках и указательных структурах. В таких случаях потоки не ускоряют вычисления, а просто параллельно ждут данные из памяти.

Подробнее в новом переводе статьи от Брайана Гоетца – одного из ключевых архитекторов экосистемы Java и главного авторитета по конкурентному и параллельному программированию в JVM.

@spring_aio