Как ломался пиннинг в Java 21 и что починили в Java 24
Виртуальные потоки задумывались как способ удешевить конкурентность и ускорить I/O. В JDK 24 сняли проблему пиннинга в synchronized, а в JDK 25 довели до стабильности ключевые улучшения вокруг Loom.
В этом материале Денис, руководитель группы R&D, рассказал, что это значит на практике и какие шаги стоит сделать уже сейчас.
Виртуальные потоки кажутся простым способом ускорить I/O. Но на Java 21 многие сталкивались со стагнацией.
Причина — пиннинг: код входит в synchronized и внутри выполняет блокирующую операцию (I/O, wait(), ожидание монитора), виртуальный поток «прибивается» к carrier-потоку и не может отмонтироваться.
Под нагрузкой это быстро исчерпывает пул carrier-потоков и «замораживает» обработку.
Часто как побочный симптом растет число соединений в CLOSE_WAIT, потому что обработчики не успевают корректно закрывать сокеты.
Что изменилось в JDK 24
В JDK 24 реализован механизм, благодаря которому виртуальные потоки больше не пиннятся внутри synchronized, включая ожидание монитора и Object.wait()): JVM умеет корректно «размонтировать/перемонтировать» поток.
Это почти полностью снимает главный источник проблем с Loom и в большинстве случаев избавляет от необходимости переписывать synchronized на ReentrantLock ради масштабируемости. Редкие источники пиннинга остались вне synchronized, например, JNI — их стоит искать профилированием и наблюдаемостью (JFR-события).
Что стало удобнее в JDK 25
Scoped Values становятся финальными — надежная альтернатива ThreadLocal для передачи неизменяемого контекста без накладных расходов и утечек. Structured Concurrency остается в статусе preview и хорошо сочетается с моделью виртуальных потоков.
Что имеет смысл сделать уже сейчас без перелома архитектуры
- Планировать переход на JDK 25, чтобы получить финальные Scoped Values и полный набор улучшений Loom.
- Запускать задачи через Executors.newVirtualThreadPerTaskExecutor() или фабрику Thread.ofVirtual() — так вы используете Loom «как задумано».
- Проаудировать горячие пути — убрать блокирующие вызовы из-под synchronized, сузить критические секции. При необходимости оставлять ReentrantLock, но не рассчитывать на него как на универсальное лекарство от пиннинга.
- Включить наблюдаемость — отслеживать события пиннинга виртуальных потоков, рост очередей/времени ожидания и аномальный CLOSE_WAIT.
- Там, где сегодня используются тяжелые ThreadLocal, по возможности переносить на Scoped Values после обновления до JDK 25 и обновлять библиотеки до версий с поддержкой Loom.
