Виртуальные потоки в Java: от устройства до миграции

Виртуальные потоки (Virtual Threads) - одно из самых значимых нововведений в Java 21, появившееся в рамках Project Loom. Это принципиально новый подход к управлению конкурентностью, который существенно упрощает разработку масштабируемых приложений.

До появления виртуальных потоков Java использовала модель 1 к 1 - каждый Thread напрямую соответствовал потоку операционной системы. Это создавало серьезные ограничения: создание тысяч потоков быстро исчерпывало ресурсы системы, вынуждая разработчиков использовать сложные асинхронные решения.

Виртуальные потоки нацелены поменять правила игры. Заявляется, что теперь можно создавать миллионы легковесных потоков без существенных накладных расходов, сохраняя при этом привычный синхронный стиль программирования. Все ли так просто и очевидно? Рассмотрим чуть подробнее.

1. Ключевые изменения

Главные отличия от традиционных потоков:

Легковесность - создание и завершение виртуального потока обходится на порядки дешевле. Если создание обычного потока требует около 2МБ памяти и системных вызовов, то виртуальный поток занимает всего несколько килобайт.

Масштабируемость - миллионы виртуальных потоков могут работать одновременно без критических накладных расходов. Ограничения теперь определяются не количеством потоков ОС, а доступной памятью кучи.

Синхронный код без потери производительности - можно писать линейный, читаемый блокирующий код, который под капотом масштабируется как асинхронный.

Совместимость с существующим API - виртуальные потоки реализуют тот же Thread API, что означает минимальные изменения в существующем коде.

Сравнительная таблица: традиционные vs виртуальные потоки

С точки зрения разработки это означает:

• Уходит необходимость в сложных асинхронных конструкциях в большинстве случаев
• Библиотеки, которые раньше блокировали потоки, теперь не создают проблем масштабируемости
• Можно использовать привычные конструкции синхронизации без опасений

С точки зрения инфраструктуры изменяется модель планирования - виртуальные потоки мультиплексируются на пул carrier threads (обычно ForkJoinPool), что требует пересмотра подходов к мониторингу и профилированию.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

    // Традиционные потоки
    ExecutorService executor = Executors.newFixedThreadPool(200);
    executor.submit(() -> {
      // обработка запроса
    });
    
    // Виртуальные потоки  
    Thread.ofVirtual().start(() -> {
      // обработка запроса
    });
    
    // Или через Executor
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
      executor.submit(() -> {
        // обработка запроса
      });
    }

2. Архитектура и внутреннее устройство

Виртуальные потоки реализованы как user-mode threads поверх JVM, которые управляются специальным планировщиком внутри JDK, а не операционной системой напрямую. Это позволяет отделить концепцию логического потока выполнения от более ограниченного ресурса - потока ОС.

Ключевые компоненты архитектуры

Virtual Thread представляет собой Java-объект (java.lang.VirtualThread), который хранит состояние выполнения задачи. В отличие от обычных потоков, виртуальный поток не привязан к конкретному потоку ОС на протяжении всего жизненного цикла.

Carrier Thread - это обычный поток ОС, который временно “несет” виртуальный поток во время его выполнения. Когда виртуальный поток блокируется на I/O операции, carrier thread освобождается и может взять на себя выполнение другого виртуального потока.

Scheduler (VirtualThreadScheduler) управляет распределением виртуальных потоков по carrier threads. По умолчанию используется специально настроенный ForkJoinPool. Scheduler отвечает за:

• Приостановку виртуальных потоков при блокирующих операциях
• Сохранение состояния стека в куче (heap)
• Возврат carrier thread в пул для других задач
• Возобновление выполнения после завершения блокирующей операции

Continuation и Stack Management - виртуальные потоки используют механизм continuations для дешевой приостановки и возобновления выполнения. Стек вызовов может быть сохранен в куче и восстановлен позже на другом carrier thread.

Общая архитектура виртуальных потоков

Диаграмма архитектуры показывает многоуровневую структуру виртуальных потоков. Каждый слой имеет свою роль: приложение создает логические потоки выполнения (Virtual Threads), планировщик управляет их распределением, carrier threads выполняют реальную работу, используя ограниченные ресурсы операционной системы. Ключевой принцип - множество виртуальных потоков мультиплексируются на небольшое количество потоков ОС.

graph TD
    subgraph "Application Layer"
        A[Приложение]
    end
    
    subgraph "Virtual Threads Layer"
        B[Virtual Thread 1]
        C[Virtual Thread 2]
        D[Virtual Thread N]
    end
    
    subgraph "Scheduler Layer"
        E((Scheduler))
    end
    
    subgraph "Carrier Threads Layer"
        F([Carrier Thread 1])
        G([Carrier Thread 2])
        H([Carrier Thread M])
    end
    
    subgraph "OS Threads Layer"
        I[OS Thread 1]
        J[OS Thread 2]
        K[OS Thread M]
    end
    
    A --> B
    A --> C
    A --> D
    
    B --> E
    C --> E
    D --> E
    
    E --> F
    E --> G
    E --> H
    
    F --> I
    G --> J
    H --> K

Работа планировщика и управление памятью

Планировщик управляет очередью готовых к выполнению виртуальных потоков, распределяет их по доступным carrier threads. Когда виртуальный поток встречает блокирующую операцию (например, чтение из сокета), JVM автоматически приостанавливает его выполнение (park), уведомляя планировщик о необходимости сохранить continuation в куче и освободить carrier thread. При завершении I/O операции система событий (epoll/kqueue) генерирует unpark событие, которое сигнализирует планировщику о необходимости вернуть виртуальный поток в очередь выполнения и назначить ему новый carrier thread.

Park/Unpark механизм представляет собой кооперативную многозадачность на уровне JVM. В отличие от традиционной вытесняющей многозадачности ОС, виртуальный поток добровольно уступает управление только при блокирующих вызовах. Операция park сериализует текущий стек вызовов (continuation) в heap память, освобождая дорогостоящий carrier thread для других задач. Unpark восстанавливает стек из heap и планирует поток к выполнению, причем восстановление может произойти на любом доступном carrier thread.

ForkJoinPool как основа планировщика выбран неслучайно - его work-stealing алгоритм идеально подходит для высокого параллелизма. Каждый carrier thread имеет локальную очередь задач (deque), работая по принципу LIFO для собственных задач и FIFO при “краже” чужих. Это минимизирует contention и cache misses, обеспечивая линейную масштабируемость до сотен carrier threads.

Continuation management - критический аспект производительности. Continuation’ы хранятся в heap как обычные Java объекты, что добавляет GC overhead, но позволяет использовать все оптимизации сборщика мусора. Типичный continuation занимает 2-8КБ, но shallow call stacks (частые в I/O intensive коде) минимизируют memory footprint. JVM оптимизирует сериализацию стеков, используя compressed OOPs и специальные data structures для frame metadata.

Event system integration обеспечивает реактивное планирование через платформо-специфичные механизмы. На Linux используется epoll с edge-triggered notifications, на macOS - kqueue, на Windows - I/O completion ports. Это позволяет одному event loop thread обслуживать миллионы соединений с latency в единицы микросекунд от completion до unpark события. Интеграция настолько тесная, что блокирующий socket.read() под капотом превращается в асинхронную операцию без изменения API.

Диаграмма управления ресурсами детализирует ключевую концепцию планировщика - как множество виртуальных потоков конкурируют за ограниченные ресурсы carrier threads. Это центральная идея, которая делает виртуальные потоки масштабируемыми. N виртуальных потоков конкурируют за M carrier threads (где N » M), а Scheduler решает, какие virtual threads выполняются сейчас, а какие ожидают или заблокированы.

graph LR
    subgraph "Resource Management"
        VT1[VT-1: Reading file]
        VT2[VT-2: HTTP call]
        VT3[VT-3: DB query]
        VT4[VT-4: Network I/O]
        VT5[VT-5: Socket read]
        VTN[VT-N: ...]
    end
    
    subgraph "Limited Carrier Threads"
        CT1([Carrier Thread 1])
        CT2([Carrier Thread 2])
        CT3([Carrier Thread 3])
    end
    
    subgraph "Scheduler Decision"
        SCHED{Scheduler
ForkJoinPool}
    end
    
    VT1 --> SCHED
    VT2 --> SCHED  
    VT3 --> SCHED
    VT4 --> SCHED
    VT5 --> SCHED
    VTN --> SCHED
    
    SCHED -->|Currently executing| CT1
    SCHED -->|Currently executing| CT2
    SCHED -->|Currently executing| CT3
    
    SCHED -.->|Blocked, continuation
stored in heap| HEAP[(Heap Storage
VT-4, VT-5, VT-N
continuations)]

Диаграмма жизненного цикла виртуального потока

Диаграмма жизненного цикла показывает временную последовательность событий в жизненном цикле одного виртуального потока, демонстрируя ключевой принцип работы: при блокирующей операции виртуальный поток не блокирует carrier thread, а освобождает его для выполнения других задач. Состояние сохраняется в памяти кучи и восстанавливается после завершения I/O операции.

sequenceDiagram
    participant VT as Virtual Thread
    participant CT as Carrier Thread
    participant S as Scheduler
    participant IO as I/O Operation
    
    VT->>CT: Запуск выполнения
    CT->>IO: Блокирующий вызов (например, socket.read())
    Note right of IO: Операция ввода-вывода
    CT-->>S: Приостановка VT (park)
    S->>S: Сохранение continuation в heap
    S->>CT: Освобождение для других задач
    
    IO-->>S: Операция завершена
    S->>CT: Назначение carrier thread
    S->>CT: Восстановление continuation
    CT->>VT: Возобновление выполнения

Практические выводы

Блокирующие I/O операции (чтение файлов, сетевые вызовы, обращения к базе данных) больше не приводят к простою дорогостоящих carrier threads. Это кардинально меняет экономику использования потоков в Java-приложениях.

CPU-интенсивные задачи не получают преимуществ от виртуальных потоков, поскольку они не содержат точек блокировки, где можно было бы приостановить выполнение.

Существующий код с synchronized блоками, ReentrantLock и другими механизмами синхронизации работает без изменений, что существенно упрощает миграцию. (Хотя и есть нюансы использования кода с synchronized, но об этом далее)

3. Ключевые сценарии использования

Веб-серверы с высокой нагрузкой на I/O - классический случай применения виртуальных потоков. Каждый HTTP-запрос может обрабатываться в отдельном виртуальном потоке, что позволяет легко масштабироваться до десятков тысяч одновременных соединений. Особенно эффективно для API Gateway, прокси-серверов и микросервисов, которые активно взаимодействуют с внешними системами.

Массовые фоновые задачи с I/O операциями получают значительные преимущества. Обработка больших объемов данных из баз данных, файловых систем или внешних API может выполняться параллельно в миллионах виртуальных потоков без риска исчерпания ресурсов системы.

ETL-процессы и пакетная обработка данных, особенно когда каждая запись требует обращения к внешним системам (обогащение данных, валидация через внешние сервисы, загрузка связанных объектов). Виртуальные потоки позволяют распараллелить такие операции без сложной асинхронной архитектуры.

Чат-боты и системы уведомлений, где каждое взаимодействие с пользователем может включать множество внешних вызовов - к API социальных сетей, системам аналитики, базам знаний. Каждая сессия может выполняться в отдельном виртуальном потоке с простой синхронной логикой.

Агрегаторы данных и системы мониторинга, которые собирают информацию из множества источников. Вместо сложных асинхронных конструкций можно использовать простые циклы с блокирующими вызовами в виртуальных потоках.

Системы интеграции и ESB (Enterprise Service Bus), где каждое сообщение проходит через цепочку обработчиков с потенциальными обращениями к внешним системам, базам данных или файловым хранилищам.

4. Риски и антипаттерны

Несмотря на очевидные преимущества, виртуальные потоки требуют внимательного подхода к проектированию и могут создавать новые проблемы при неправильном использовании.

Thread Pinning и как его избежать

Thread pinning - критическая проблема виртуальных потоков в Java 21, когда виртуальный поток не может быть снят с carrier thread во время блокирующей операции. Это происходит в двух основных случаях:

Synchronized блоки и методы (Java 21) приводят к pinning, поскольку JVM отслеживает владение монитором на уровне platform thread, а не виртуального потока. При попытке размонтировать виртуальный поток внутри synchronized блока произошла бы потеря взаимного исключения. Решение в Java 21 - использовать java.util.concurrent.locks.ReentrantLock вместо synchronized.

JNI (Java Native Interface) вызовы также вызывают pinning, так как нативный код выполняется в контексте конкретного потока ОС. Критически важно минимизировать время выполнения JNI-вызовов или выносить их в отдельные обычные потоки.

Для диагностики pinning можно использовать JVM флаг:

1

-Djdk.tracePinnedThreads=full

⚠️ Использование jdk.tracePinnedThreads может вызывать зависания приложения, поскольку stack trace печатается во время выполнения критичного кода. Рекомендуется использовать это свойство только в dev/test окружениях.

Решение проблемы pinning в Java 24

Java 24 устраняет основную часть проблем thread pinning через JEP 491: “Synchronize Virtual Threads without Pinning”. Это изменение решает практически все случаи pinning, связанные с synchronized конструкциями.

Основные улучшения в Java 24:

Устранение synchronized pinning - JVM теперь отслеживает владение мониторами на уровне виртуальных потоков, а не platform threads. Виртуальный поток может размонтироваться внутри synchronized методов и блоков, освобождая carrier thread для других задач.

Улучшенная работа с блокировками - когда виртуальный поток блокируется при попытке получить уже занятый монитор, он размонтируется и освобождает carrier thread. После освобождения монитора виртуальный поток возвращается в планировщик для повторного монтирования.

Object.wait() без pinning - вызовы Object.wait() и Object.notify() больше не приводят к pinning. Виртуальный поток размонтируется во время ожидания и монтируется обратно при пробуждении.

Обновленная диагностика - JFR события jdk.VirtualThreadPinned теперь генерируются только для случаев JNI pinning и содержат расширенную информацию о причине pinning и идентификаторе carrier thread.

Упразднение jdk.tracePinnedThreads - системное свойство больше не действует и не влияет на работу JVM, что устраняет риск зависаний при диагностике.

Практические следствия для Java 24:

Выбор между synchronized и java.util.concurrent.locks теперь основывается на функциональных требованиях, а не на соображениях производительности виртуальных потоков. Для нового кода можно использовать synchronized для простых случаев и ReentrantLock для сложной логики блокировок.

Миграция существующего кода с ReentrantLock обратно на synchronized не требуется, но возможна без потери производительности.

Оставшиеся случаи pinning в Java 24:

• Загрузка классов с блокировкой
• Выполнение внутри class initializer
• JNI вызовы с обратными вызовами в Java код

Эти случаи встречаются не так часто и обычно не создают проблемы масштабируемости в типичных приложениях.

Java 25: LTS релиз и финализация Scoped Values ✏️ (Updated 20.09.2025)

Java 25, выпущенная в сентябре 2025 года, стала первым LTS релизом после Java 21. Это означает минимум 8 лет поддержки от Oracle, что делает Java 25 оптимальной точкой входа для enterprise-проектов, планирующих использовать виртуальные потоки в production.

Что включает Java 25:

Все улучшения виртуальных потоков из Java 24, включая устранение synchronized pinning (JEP 491). Финализация Scoped Values API (JEP 506) - новый механизм для работы с контекстом потоков.

Scoped Values: эффективная альтернатива ThreadLocal

Scoped Values (JEP 506) - это новый API для передачи неизменяемого контекста между компонентами приложения, специально оптимизированный для виртуальных потоков.

Зачем нужны Scoped Values:

ThreadLocal создает копию данных для каждого потока. С миллионами виртуальных потоков это приводит к значительному потреблению памяти. Время жизни ThreadLocal данных неопределенно, что создает риск утечек. Scoped Values решают обе проблемы, предоставляя четко ограниченную область видимости и автоматическую очистку.

Ключевые преимущества Scoped Values:

• Четко определенная область видимости - данные существуют только внутри конкретного блока кода
• Автоматическая очистка - исключает утечки памяти
• Неизменяемость - гарантирует thread-safety
• Меньше накладных расходов по памяти и времени по сравнению с ThreadLocal
• Автоматическое наследование дочерними потоками

Сравнение ThreadLocal и ScopedValue:

Когда использовать:

Scoped Values оптимальны для передачи request context (user, tenant, trace ID), security context, временных конфигураций. ThreadLocal остается актуальным для legacy кода и случаев, где действительно нужна мутабельность.

Подробнее о Scoped Values с примерами использования:

• JEP 506: Scoped Values
• Oracle Java 25 Documentation: Scoped Values

Ситуации, когда виртуальные потоки неэффективны

CPU-intensive задачи не получают преимуществ, поскольку не содержат блокирующих операций. Более того, overhead от context switching может снизить производительность по сравнению с обычными потоками.

Системы реального времени с жесткими требованиями к latency могут пострадать от непредсказуемости планировщика виртуальных потоков и garbage collection паузы от хранения continuation в куче.

Приложения с интенсивным использованием ThreadLocal переменных могут столкнуться с повышенным потреблением памяти, поскольку каждый виртуальный поток создает собственную копию ThreadLocal данных.

Проблемы совместимости

Legacy библиотеки с synchronized интенсивным кодом создают bottleneck через pinning, сводя на нет преимущества виртуальных потоков.

Долгие блокировки и несовместимые библиотеки - виртуальные потоки эффективны только при коротких блокировках (обычно I/O операции). Долгие блокировки на мьютексах или семафорах могут привести к исчерпанию пула carrier threads.

Библиотеки, использующие пулы соединений с ограниченным размером, могут создавать contention точки. Необходимо пересматривать размеры пулов с учетом возможного увеличения количества одновременных соединений.

Некоторые мониторинговые системы и profiler’ы могут некорректно работать с большим количеством виртуальных потоков, показывая искаженную статистику или вызывая performance degradation.

5. Интеграция с JDBC и Hibernate

JDBC драйверы в основном совместимы с виртуальными потоками, поскольку используют стандартные блокирующие I/O операции. Однако требует внимания конфигурация connection pool’ов.

Настройка Connection Pool’ов может потребовать пересмотра. Традиционные размеры пулов (10-50 соединений) рассчитывались на ограниченное количество потоков. С виртуальными потоками можно рассмотреть увеличение размера пула до сотен соединений, поскольку idle соединения не блокируют дорогостоящие ресурсы.

HikariCP конфигурация для виртуальных потоков может включать:

• Увеличение maximumPoolSize до 200-500
• Установку minimumIdle в соответствии с обычной нагрузкой
• Настройку leakDetectionThreshold с учетом возросшего количества соединений

Hibernate Session Management остается прежним, но следует учитывать, что каждый виртуальный поток может иметь собственную сессию. При использовании session-per-thread паттерна нужно контролировать время жизни сессий, чтобы избежать утечек памяти.

Транзакционность работает стандартно, но длительные транзакции могут привести к database lock contention при высоком параллелизме. Рекомендуется использовать более короткие транзакции и optimistic locking где возможно. Хотя это справедливо и вне контекста использования виртуальных потоков.

Database Connection Validation становится важной при большом количестве соединений. Рекомендуется настроить validation query и connection timeout’ы для быстрого обнаружения проблем с сетью или базой данных.

6. Observability и отладка

Мониторинг виртуальных потоков требует адаптации существующих подходов, поскольку традиционные метрики потоков становятся менее релевантными.

JVM метрики нуждаются в расширении. Стандартные MBean’ы показывают только carrier threads, а не виртуальные. Для полной картины используйте:

• Новые MBean’ы для virtual threads (VirtualThreadSchedulerMXBean)
• Метрики создания/завершения виртуальных потоков
• Статистику pinning событий

Настройка JVM флагов для диагностики:

1
2
3
4

-Djdk.virtualThreadScheduler.parallelism=N    # Количество carrier threads
-Djdk.virtualThreadScheduler.maxPoolSize=M    # Максимальный размер пула
-Djdk.tracePinnedThreads=full                  # Трассировка pinning (Java 21)
-XX:+UnlockDiagnosticVMOptions                 # Включение диагностических опций

JDK Flight Recorder поддерживает виртуальные потоки начиная с Java 21. Новые события включают:

• VirtualThreadStart/VirtualThreadEnd
• VirtualThreadPinned
• VirtualThreadSubmitFailed

Distributed Tracing требует адаптации. Trace context должен правильно передаваться между виртуальными потоками. Большинство современных tracing библиотек (Micrometer, OpenTelemetry) уже поддерживают виртуальные потоки.

Heap Memory Monitoring становится более важным, поскольку continuation’ы хранятся в куче. Рекомендуется отслеживать рост heap usage и GC активность при увеличении количества виртуальных потоков.

Application Metrics должны учитывать новые паттерны:

• Количество активных виртуальных потоков
• Время выполнения задач в виртуальных потоках
• Frequency of pinning events
• Carrier thread utilization

7. Чек-лист миграции

Стратегии миграции

Градуальная миграция - рекомендуемый подход для production систем. Начать с изолированных компонентов:

1. Фоновые задачи и scheduled jobs
2. Внешние API вызовы
3. Асинхронные обработчики событий
4. Постепенно переходите к core business logic

Полный переход оправдан только для новых проектов или при существенном рефакторинге системы.

Особенности миграции на Java 21 vs 24

Если переезжаете на Java 21, необходимо внимательно проверять использование synchronized блоков, JNI-вызовов и legacy библиотек из-за риска pinning. Рекомендуется рефакторинг hot path’ов на ReentrantLock.

Если сразу переходите на Java 24, улучшения в синхронизации виртуальных потоков позволяют безопасно использовать synchronized без риска pinning, что упрощает миграцию и снижает объем рефакторинга.

Миграция на Java 25 ✏️ (Updated 20.09.2025)

Java 25 (сентябрь 2025) как LTS релиз включает все улучшения из Java 24, включая решение проблемы synchronized pinning, плюс финализацию Scoped Values API. Это делает её привлекательной целевой версией для проектов, планирующих использовать виртуальные потоки на версии Java с долгосрочной поддержкой.

Однако миграция с ранних версий (Java 8/11/17) напрямую на Java 25 может быть трудоемкой и проблематичной. Необходим тщательный аудит существующего кода на совместимость, поскольку накопилось множество существенных изменений за годы. Объем необходимых изменений может оказаться настолько большим, что прямой прыжок через несколько мажорных версий станет нецелесообразным.

Даже для новых проектов рекомендуется дождаться стабилизации экосистемы и проанализировать готовность критичных библиотек, фреймворков и инструментов мониторинга. Java 25 имеет смысл выбирать для production-систем с консервативной политикой обновлений после того, как экосистема достаточно адаптируется к новому релизу.

Аудит существующего кода

Инвентаризация использования потоков:

• Найти все места создания Thread/Executor объектов
• Проанализировать использование ThreadPoolExecutor
• Выявить CompletableFuture chains, которые можно упростить
• Определить synchronized блоки в hot path’ах

Анализ библиотек:

• Проверить JDBC драйверы на совместимость
• Оценить использование JNI библиотек
• Найти legacy компоненты с intensive synchronized usage
• Проверить HTTP клиенты и их configuration

Профилирование блокировок:

• Использовать async-profiler для анализа thread contention
• Выявить долгие блокировки и bottleneck’и
• Проанализировать database connection usage patterns

Потенциальный timeline миграции

Фаза 1 (1-2 недели): Подготовка

• Обновление до Java 21+
• Настройка мониторинга и метрик
• Тестирование в dev/staging окружениях
• Обучение команды

Фаза 2 (2-4 недели): Пилотное внедрение

• Миграция фоновых задач
• A/B тестирование на части трафика
• Анализ performance метрик
• Устранение выявленных проблем

Фаза 3 (4-8 недель): Полное развертывание

• Постепенное увеличение нагрузки на виртуальные потоки
• Мониторинг stability и performance
• Fine-tuning конфигурации
• Документирование best practices

Фаза 4: Оптимизация

• Refactoring synchronized -> ReentrantLock где критично
• Optimization connection pool sizes
• Удаление ненужного асинхронного кода
• Performance tuning JVM parameters

Критерии успеха миграции

Технические метрики:

• Снижение memory footprint от потоков
• Увеличение throughput при высокой нагрузке
• Уменьшение response time variability
• Стабильность под peak load

Качество кода:

• Упрощение асинхронной логики
• Уменьшение количества callback’ов
• Улучшение читаемости кода
• Снижение complexity metrics

Операционные показатели:

• Стабильность в production
• Отсутствие утечек памяти
• Корректная работа мониторинга
• Простота troubleshooting

Виртуальные потоки представляют собой эволюционный шаг в развитии Java concurrency, который позволяет писать простой, понятный код без жертв в производительности и масштабируемости.

Полезные ресурсы

Общее

• JEP 444: Virtual Threads
• OpenJDK Project Loom

Архитектура и документация

• Oracle Virtual Threads Guide. Java 21
• Oracle Virtual Threads Guide. Java 24

Pinning и производительность

• JEP 491: Pinning Diagnostics
• Todd Ginsberg: Virtual Thread Pinning (объяснение)
• Java 24 - Thread Pinning Revisited

Практика и фреймворки

• Embracing Virtual Threads
• Spring Framework 6.1 / Spring Boot 3.2 & Virtual Threads
• Baeldung: Virtual Threads в Spring Boot