Async-стадии без Executor выполняются в ForkJoinPool.commonPool — он общий на всю JVM и размером примерно число ядер − 1. Блокирующие вызовы (HTTP, БД, get чужого future) занимают его потоки, и встаёт всё, что им пользуется: другие цепочки, parallel stream, библиотеки.
А ещё В контейнере с 1–2 CPU commonPool совсем крошечный
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Почему commonPool не подходит для ввода-вывода. Он задуман для коротких вычислительных задач без блокировок; его параллелизм равен availableProcessors() - 1. На машине с 4 ядрами — 3 потока. Три сетевых вызова по секунде — и все async-стадии приложения ждут.
Особенность контейнеров. JVM видит лимит CPU контейнера: при 1 CPU commonPool может состоять из одного потока, а async-задачи вообще выполняться в новом потоке на каждую.
Правильно:
sottoExecutorService io = Executors.newVirtualThreadPerTaskExecutor();
supplyAsync(() -> http.get(url), io)
.thenApplyAsync(this::parse, cpuPool);Блокирующие стадии — в отдельный пул (ограниченный, именованный, или виртуальные потоки), вычислительные можно оставить в commonPool.
То же касается parallelStream() с сетевыми вызовами внутри.
Один верный вариант. Подумайте, потом откройте ответ.
Ограничения Future, асинхронная композиция CompletableFuture, async-варианты с пулами и обработка ошибок.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.