В опубликованной 27 августа 2026 года записи в блоге JetBrains рассматривает три компонента Project Loom в IntelliJ IDEA: Virtual Threads, Scoped Values и Structured Concurrency. Основная идея заключается не в добавлении отдельных API, а в решении трёх взаимосвязанных проблем конкурентных приложений Java: масштабируемости, передачи контекста между задачами и управления жизненным циклом потоков и ошибками.
В материале объясняется, что написание многопоточного кода по-прежнему подвержено утечкам потоков, подавлению исключений, состояниям гонки и задержкам отмены. Кроме того, традиционная зависимость от пулов потоков и CompletableFuture может привести к тому, что логика отмены и обработки ошибок окажется распределённой по нескольким ветвям, из-за чего повышается вероятность не обновить её при добавлении новой параллельной задачи.
Виртуальные потоки снижают стоимость ожидания
Виртуальные потоки основаны на JEP 444 и являются стабильными начиная с Java 21. В отличие от платформенных потоков, связанных с потоками операционной системы, виртуальные потоки управляются JVM и могут создаваться с гораздо меньшими затратами. JetBrains отмечает, что создание виртуального потока занимает микросекунды, а не миллисекунды, и что поток освобождает платформенный поток, когда ожидает базу данных, сетевое соединение, файл или механизм синхронизации.
Это делает их особенно подходящими для рабочих нагрузок, зависящих от блокирующих операций, поскольку необходимость заранее настраивать размер пулов потоков уменьшается. В материале также упоминается, что Java 24 посредством JEP 491 представила улучшение, позволяющее виртуальным потокам, заблокированным внутри методов или операторов synchronized, освобождать платформенный поток вместо того, чтобы удерживать его.
Общий контекст без проблем ThreadLocal
Scoped Values, ставшие стабильными начиная с Java 25 согласно JEP 506, решают другую проблему. Приложениям часто требуется передавать такие данные, как идентификатор сессии или идентификатор трассировки, в различные части запроса. Обычно это делалось с помощью ThreadLocal, однако его значения изменяемы и остаются связанными с временем жизни потока, если их не удалить вручную, что может привести к утечкам памяти или проблемам безопасности. JetBrains отмечает, что такие фреймворки, как Spring, могут использовать ThreadLocal внутри даже в тех случаях, когда разработчик напрямую его не применяет.
ScopedValue предлагает модель, основанную на однократной привязке значения в определённой области с последующим автоматическим предоставлением этого значения коду, выполняющемуся внутри неё, и его очисткой после завершения области. Привязку нельзя изменить изнутри области, а при использовании со структурированной конкурентностью значение передаётся дочерним задачам без явной передачи контекста. На практике это уменьшает количество контрольных точек, за которыми разработчику необходимо следить при выполнении параллельных задач.
Структурированная конкурентность связывает задачи с определённым временем жизни
Structured Concurrency, основанная на JEP 533, направлена на решение структурных проблем параллельного кода. Однако в Java 27 она всё ещё находится на стадии седьмого предварительного просмотра, поэтому JetBrains пока не рекомендует использовать её в производственных средах. Концепция заключается в том, чтобы рассматривать группу связанных задач как единую рабочую единицу с владельцем, временем жизни и чёткой политикой отказа.
В примере, который приводит JetBrains, приложение параллельно получает историю заказов клиента и рекомендации по товарам, чтобы собрать профиль клиента. С помощью StructuredTaskScope можно задать тайм-аут в две секунды, потребовать успешного выполнения обеих задач и автоматически отменить другую задачу, если одна из них завершится с ошибкой или истечёт время ожидания. Вместо повторения вызовов cancel() в ветвях обработки исключений политика отмены становится частью области задачи.
В материале также рассматривается другой случай, не требующий успешного выполнения всех задач: если приложение получает рекомендации из двух кэшей и ему достаточно первого успешного ответа, можно использовать anySuccessfulOrThrow(). После получения успешного результата область закрывается, а другая задача автоматически отменяется. Если же обе задачи завершаются с ошибкой, выбрасывается исключение, объясняющее причину сбоя.
Что меняется внутри IntelliJ IDEA?
Преимущество заключается не только в синтаксисе кода. Начиная с IntelliJ IDEA 2026.1 виртуальные потоки, создаваемые внутри StructuredTaskScope, объединяются в контейнеры, представляющие их области, благодаря чему структура связи между родительской задачей и дочерними задачами становится видимой в отладчике. Поэтому дамп потоков показывает не просто плоский список потоков общего пула, а даёт более точное представление о задачах, принадлежащих одному и тому же запросу.
Чтобы опробовать эти функции, разработчику требуется Java 27, которая, согласно материалу, является версией Early Access, а также настройка уровня языка для использования экспериментальных функций. IntelliJ IDEA позволяет загрузить JDK из настроек проекта и показывает встроенные подсказки при использовании таких инструментов, как SDKMAN! или asdf, для управления версиями JDK. Начальную структуру StructuredTaskScope можно создать с помощью шаблона live template sts.
Редакционный комментарий certi.news
Фактическое изменение заключается в переносе части управления параллелизмом с ручной ответственности разработчика на модель, в которой структура кода описывает время жизни задачи и её политику отказа. Virtual Threads решают проблему стоимости масштабирования, Scoped Values упорядочивают передачу контекста, а Structured Concurrency стремится сделать отмену и распространение ошибок предсказуемыми. Совместное использование этих функций может уменьшить объём повторяющегося кода в приложениях, выполняющих несколько операций ожидания параллельно.
Однако границы развития очевидны: Structured Concurrency ещё не стала стабильной, а на момент публикации материала Java 27 была версией раннего доступа. Поэтому запись в блоге не доказывает, что каждое приложение автоматически получит улучшения, и не отменяет необходимости тестировать поведение библиотек и фреймворков, используемых вместе с этими моделями. Текущая ценность для разработчиков заключается в понимании этого подхода и его безопасной проверке, при этом экспериментальные функции следует не использовать в производственной среде до стабилизации их интерфейсов и накопления достаточного эксплуатационного опыта.