🔼 Virtual Threads: где спасают, а где нет

С Java 21 virtual threads стали stable (JEP 444). Вместо тяжёлых OS-тредов — легковесные потоки, которыми управляет JVM. Код остаётся синхронным и читаемым, а рантайм под капотом делает M:N scheduling: когда виртуальный тред блокируется на I/O, он паркуется и отпускает carrier thread другому.

На практике это значит одно: Executors.newFixedThreadPool(200) с танцами вокруг размера пула заменяется на Executors.newVirtualThreadPerTaskExecutor(). Блокирующий вызов больше не сжигает OS-тред, пока ждёт ответа от базы.

🔹 Где работает

— веб-сервисы с большим числом конкурентных запросов;
— I/O-heavy бэкенды (база, сеть, файлы);
— замена реактивщины там, где она была вынужденной, а не осознанной.

🔹 Где не работает и не должно

— connection pool базы всё ещё bottleneck.
— CPU-bound задачи не получают выигрыша, т.к. carrier threads и так заняты вычислениями.
— synchronized блоки пинят виртуальный тред к carrier thread (починили в JDK 24). Если у вас hot path с synchronized, переходите на ReentrantLock.
— Внешние API с rate limit'ами никуда не денутся.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava