Project Loom
Тема дорожной карты · Java
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-вызовы) без потери масштабируемости. Project Loom приземлился в JDK 21 как стабильная функция через Thread.ofVirtual().start(task), Executors.newVirtualThreadPerTaskExecutor() и API StructuredTaskScope для компоновки конкурентных подзадач с чёткими временами жизни и семантикой отмены. 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-блока (пиннит carrier — теряет смысл); чрезмерное использование records для mutable-концептов (поля records — final); баги reflection в GraalVM native image (требуют файлы конфигурации); расчёт, что cancellation Reactor идентичен interruption virtual thread (разная семантика).