Parallel stream выполняется в общем ForkJoinPool.commonPool — одном на JVM, размером «ядра − 1». Блокирующий HTTP-вызов занимает его потоки, и встают все parallel stream и async-стадии приложения, включая чужие библиотеки.
А ещё Parallel stream — только для CPU-bound и больших объёмов
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Общий ForkJoinPool задумывался под короткие вычислительные задачи, которые никогда не блокируются. Стоит поместить туда сетевой вызов на секунду — и все остальные параллельные стримы приложения, включая чужие библиотеки, встают в очередь. Отладить это тяжело: тормозит код, который вы не меняли. Варианты решения: не использовать parallel stream для блокирующих операций вовсе; выполнить стрим внутри задачи, отправленной в собственный ForkJoinPool (известный обходной приём); либо взять ExecutorService или виртуальные потоки, которые для такой нагрузки подходят гораздо лучше. Общее правило: parallel stream — инструмент для CPU-bound обработки больших объёмов данных в памяти, и никак не для ввода-вывода.
Один верный вариант. Подумайте, потом откройте ответ.
Состояние на поток и утечки в пулах, InheritableThreadLocal, work-stealing в ForkJoinPool и общий пул parallel streams.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto