Project Loom

Project Loom — это инициатива OpenJDK, переосмысляющая Java Concurrency путём введения Virtual Threads — лёгких, управляемых JVM потоков, достаточно дешёвых для создания миллионами, фундаментально меняющих то, как пишутся I/O-ёмкие Java-приложения. До Project Loom высококонкурентные Java-серверы полагались на реактивные фреймворки (Project Reactor, RxJava), чтобы избежать блокировки платформенных потоков — дорогостоящих ресурсов уровня ОС; Virtual Threads, реализованные через Project Loom, позволяют разработчикам писать простой блокирующий код (Thread.sleep(), JDBC-запросы, HTTP-вызовы) без потери масштабируемости. Virtual Threads стали стабильной функцией в JDK 21 через Thread.ofVirtual().start(task) и Executors.newVirtualThreadPerTaskExecutor(); а вот API StructuredTaskScope для компоновки конкурентных подзадач с чёткими временами жизни и семантикой отмены до сих пор остаётся preview: JEP 453 в JDK 21, затем пятый preview (JEP 505) в JDK 25 с переработанным API StructuredTaskScope.open() и Joiner, шестой (JEP 525) в JDK 26 и седьмой (JEP 533) в JDK 27. Scoped Values при этом финализированы в JDK 25 — подробнее обе темы разобраны в узлах Structured Concurrency и Scoped Values этого роадмапа. Spring Boot 3.2+ прозрачно направляет обработку запросов Tomcat и WebFlux к Virtual Threads при spring.threads.virtual.enabled=true, позволяя существующему блокирующему коду Spring, Hibernate и JDBC обрабатывать тысячи конкурентных запросов без настройки пула потоков. Project Loom и Virtual Threads представляют собой наиболее значимое дополнение к Java Concurrency со времён CompletableFuture и Fork/Join-фреймворка, и понимание того, как JVM планирует Virtual Threads на потоках-носителях (платформенных) через ForkJoinPool с похищением работы, является ключом к диагностике закрепления, взаимоблокировок и проблем производительности.

Как это работает

Project Loom — это Java 17/21 LTS с фичами, меняющими, как пишется код: records (immutable data), sealed-типы (закрытая иерархия), pattern matching для switch (21+), текстовые блоки, var, switch-выражения, records как pattern-deconstructed типы. Virtual threads (21) драматически упрощают concurrent server-код. Reactive-программирование (Project Reactor, RxJava) ещё актуально, но virtual threads сужают его нишу.

Когда применять

Таргет 21 LTS для новых проектов — одни virtual threads стоят апгрейда. Records — для DTO, sealed-типы — для конечных иерархий, pattern matching — при диспетчеризации по типу. Миграция с reactive (Project Reactor) на virtual threads — где читаемость бьёт async-stream-преимущества. GraalVM native image — когда важны быстрый старт + низкая память (CLI-тулзы, serverless).

Типичные ошибки

Ловушки Project Loom: блокировка на virtual thread внутри synchronized-блока на Java 21–23 (до JDK 24 она пиннила carrier — JEP 491 в JDK 24 это устранил, но на 21–23 ловушка актуальна); чрезмерное использование records для mutable-концептов (поля records — final); баги reflection в GraalVM native image (требуют файлы конфигурации); расчёт, что cancellation Reactor идентичен interruption virtual thread (разная семантика).

Связанные понятия

• Современная Java
• Records
• Sealed classes
• Pattern matching