|
|
От: |
Serginio1
|
https://habrahabr.ru/users/serginio1/topics/ |
| Дата: | 18.12.25 16:10 | ||
| Оценка: | |||
·>Опять неспособность читать. Там ещё следующая глава в статье. Хинт: текущая версия это Java 25.S>>Выводы по Java 21
Что (вроде бы) остается опасным даже в 24–25
На границе 24–25 Java виртуальные потоки в почти идеальном состоянии, но важно помнить про «наследие» до Java 21:
Библиотеки, полагающиеся на ThreadLocal, например, старые реализации MDC в логировании, становятся узким местом при миллионах виртуальных потоков.
Вызовы через JNI по‑прежнему блокируют carrier thread.
Долгоживущие VT, например, бесконечные воркеры, = неоптимальное использование.
Когда виртуальные потоки — must have, а когда лучше не надо
Хорошие кейсы
Web-сервисы с пулами потоков и независимыми запросами, например, Tomcat, Jetty. После Java 25, где JEP 491 стабилен, можно смело включать — обработка тысяч параллельных запросов без издержек на thread pool.
HTTP-клиенты — практически «бесплатный» прирост производительности, можно запускать тысячи исходящих запросов без перегрузки потоков.
Параллельная обработка задач внутри бизнес-логики — каждый шаг в своем виртуальном потоке, без shared state.
Data-pipelines и ETL другая сложная ветвистая многопоточность — также можно смело переводить = упрощение структур многопоточности и дебага.
Плохие кейсы
Долгоживущие потоки/воркеры. Не используйте VT так же, как использовали старые: их не нужно пулить и держать в бесконечном цикле весь runtime.
Неоптимизированные библиотеки с ThreadLocal и большим числом блокирующих нативных вызовов — прироста не будет, скорее наоборот.
Вызовы через JNI могут навсегда занять carrier thread = потеря масштабируемости.
[q]
Простые советы, если вы уже перешли на свежую Java или только готовитесь
Мониторьте pinned-потоки. Несмотря на прогресс, проблемы с виртуальными потоками возможны, например, из-за JNI. Следите, чтобы не поймать кейсы «зависаний», как в нашем примере и у Netflix.