Не пулить (поток на задачу), применять для блокирующего ввода-вывода, помнить, что ThreadLocal на миллионах потоков дорог, и ограничивать доступ к внешним ресурсам семафором — пул соединений к БД от виртуальных потоков не вырастет.
А ещё Ожидание на synchronized до JDK 24 закрепляло несущий поток
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Смысл виртуальных потоков в том, что блокировка перестаёт быть дорогой: поток отцепляется от несущего платформенного и не удерживает его. Отсюда: пул виртуальных потоков — антипаттерн, задача получает свой поток. Для вычислительных задач выигрыша нет — там по-прежнему упираются в ядра, и уместен обычный пул или Fork/Join. Важное предупреждение про масштаб: миллион потоков с ThreadLocal — это миллион копий значения. И отдельно стоит сказать вслух, что снятие ограничения на число потоков лишь передвигает узкое место дальше — в пул соединений к базе или в лимиты внешнего API, которые от этого шире не становятся.
Несколько верных вариантов. Подумайте, потом откройте ответ.
Лёгкие потоки JVM, монтирование на carrier, когда их применять, почему не пулят и проблема pinning.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto