Віртуальні потоки Java: коли вони прискорюють сервер, а коли не допомагають

Віртуальні потоки стали стандартною можливістю Java у JDK 21. Вони дозволяють серверу підтримувати велику кількість одночасних завдань у знайомій моделі «один потік на запит», не резервуючи окремий системний потік на весь час очікування мережі або бази даних. Це може суттєво спростити код із блокувальним введенням-виведенням, але не робить обчислення швидшими й не усуває обмеження зовнішніх сервісів.

Віртуальний потік не дорівнює системному

Звичайний platform thread у Java пов’язаний із потоком операційної системи й залишається дорогим ресурсом. Тому сервери використовують пули обмеженого розміру, а асинхронні фреймворки намагаються не блокувати ці потоки під час очікування. Віртуальний потік реалізує JDK: багато таких потоків по черзі виконуються на меншій кількості системних carrier threads.

Коли віртуальний потік викликає підтримувану блокувальну операцію введення-виведення, JDK може призупинити його й звільнити carrier для іншого завдання. Код при цьому залишається послідовним: винятки, стек викликів і локальні змінні поводяться звично. Розробнику не потрібно перетворювати кожну операцію на ланцюжок callback або реактивний pipeline.

Головна перевага — масштабування очікування

Віртуальні потоки особливо корисні, коли застосунок обробляє багато незалежних запитів, що більшу частину часу очікують мережу, диск або базу даних. Типовий приклад — API, яке звертається до кількох зовнішніх сервісів. Тисячі запитів можуть бути логічно активними, хоча процесор одночасно виконує лише невелику частину роботи.

Якщо навантаження переважно процесорне — кодування відео, шифрування великих масивів або складне чисельне обчислення — кількість ядер залишається межею. Десять тисяч віртуальних потоків не створять додаткових процесорів і можуть додати накладні витрати. Для CPU-bound завдань важливіший контроль паралелізму, ніж здатність дешево створювати потоки.

Віртуальні потоки не потрібно об’єднувати в пул

OpenJDK прямо рекомендує створювати новий віртуальний потік для кожного завдання, а не повторно використовувати малий пул. Пул вирішує проблему дорожнечі системних потоків; віртуальні потоки за задумом дешеві й численні. Обмежувати ними конкуренцію до зовнішнього ресурсу — неправильний рівень абстракції.

Якщо база даних дозволяє 50 з’єднань, застосунок однаково повинен обмежити одночасні запити приблизно цією місткістю. Для цього використовують пул з’єднань, семафор або інший явний контроль ресурсу. Необмежена кількість віртуальних потоків може лише створити величезну чергу перед тим самим вузьким місцем.

Міграція може бути локальною

Найбезпечніший шлях — вибрати один сервіс із чітким профілем очікування й замінити виконавець завдань на варіант, що створює віртуальний потік для кожної операції. Бізнес-логіку часто не потрібно переписувати. Синхронні клієнти HTTP і JDBC можуть працювати у звичайному послідовному стилі, якщо бібліотеки сумісні з актуальним JDK.

Не варто одночасно змінювати модель потоків, фреймворк і протокол бази даних. Інакше вимірювання не покаже причину результату. Спочатку фіксують базові показники, виконують мінімальну міграцію, тестують під контрольованим навантаженням і лише після цього розширюють охоплення.

JDK 24 усунув важливий випадок pinning

У ранніх реалізаціях віртуальний потік, який блокувався всередині synchronized, міг залишатися прикріпленим до carrier thread. Часте й тривале pinning обмежувало масштабування. JEP 491, реалізований у JDK 24, змінив роботу моніторів так, щоб блокування в більшості таких випадків дозволяло звільняти carrier.

Це не означає, що pinning повністю зник. Він може залишатися під час окремих переходів у native code або роботи JVM. Команда має перевіряти бібліотеки й спостерігати за застосунком на тій версії JDK, яку використовує в продакшені. Порада механічно замінити кожен synchronized на ReentrantLock уже не є універсальною для JDK 24 і новіших.

ThreadLocal може непомітно збільшити пам’ять

Віртуальні потоки підтримують thread-local змінні, що полегшує сумісність зі старим кодом. Але припущення, безпечне для сотні системних потоків, стає дорогим для сотень тисяч віртуальних. Великий об’єкт, кеш або контекст, записаний у кожен ThreadLocal, множиться на кількість активних завдань.

Під час аудиту потрібно знайти власні й бібліотечні ThreadLocal, оцінити розмір значень і переконатися, що вони очищаються. Контекст запиту краще передавати явно або через сучасні механізми структурованого контексту, якщо вони підходять і стабільні у вибраній версії платформи. Сам факт завершення короткого потоку не виправляє пікове споживання пам’яті.

Спостережуваність потребує іншого масштабу

Звичайний thread dump із десятками потоків можна переглянути вручну. Дамп із сотнями тисяч віртуальних потоків потребує агрегації за станом, стеком і завданням. JDK має засоби спостереження за віртуальними потоками, включно з новим форматом дампів і подіями Java Flight Recorder, але сторонні агенти профілювання слід перевіряти на сумісність.

Не потрібно логувати створення й завершення кожного потоку як окрему подію за замовчуванням. Корисніші метрики — кількість активних завдань, час очікування зовнішніх ресурсів, заповнення пулу з’єднань, тривалість черги та частота відмов. Трасування повинно зберігати зв’язок між запитом і дочірніми операціями незалежно від carrier thread.

Тайм-аути й скасування залишаються обов’язковими

Дешевий потік легко створити, але зависле завдання однаково утримує пам’ять, контекст і залежності. Кожен мережевий виклик повинен мати обґрунтований тайм-аут. Коли запит клієнта скасований або перевищив загальний бюджет часу, дочірні операції також мають припинитися, а не продовжувати роботу у фоні.

Віртуальні потоки добре поєднуються зі структурованою конкурентністю як ідеєю: дочірні завдання належать конкретній операції, а помилка або скасування має передбачуваний життєвий цикл. Але статус відповідних API залежить від версії JDK, тому в продакшені потрібно відрізняти стандартні можливості від preview-функцій.

Бенчмарк має відтворювати реальне вузьке місце

Тест із sleep демонструє, що JDK може підтримувати багато очікувань, але не передбачає поведінку застосунку. Потрібні реальні драйвери, TLS, серіалізація, ліміти бази даних і профіль затримок. Варто порівнювати однакові сценарії за throughput, p95/p99, використанням CPU, пам’яті та кількістю з’єднань.

У статті TechPulse про архітектурні рішення, що переживають фреймворки, описано цінність стабільних меж. Матеріал про витрати на спостережуваність нагадує, що додаткові метрики й трасування також мають операційну ціну.

Backpressure нікуди не зникає

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

Ліміти повинні бути пов’язані з реальною місткістю бази, API чи CPU, а не з кількістю carrier threads. Для пріоритетних і фонових операцій доцільні окремі бюджети, щоб масова індексація не витіснила інтерактивні запити.

Фреймворк може приховати власний пул

Навіть якщо контролер виконується у віртуальному потоці, бібліотека може передати роботу до внутрішнього executor із малою кількістю platform threads. Тоді очікуване масштабування зникне в черзі. Під час профілювання потрібно дивитися на весь шлях запиту: вебсервер, HTTP-клієнт, драйвер бази, DNS, TLS і сторонні SDK.

Особливо уважно перевіряють адаптери між реактивним і блокувальним кодом. Подвійне планування може додати перемикання без користі. Мета міграції — спростити модель і зняти конкретне обмеження, а не формально збільшити кількість віртуальних потоків.

Контрольний план впровадження

1. Знайдіть сервіс із великою кількістю блокувального I/O та стабільним тестом навантаження.
2. Оновіть JDK і перевірте сумісність фреймворку, драйверів та агентів.
3. Створюйте віртуальний потік на завдання, але окремо обмежуйте дефіцитні ресурси.
4. Перевірте ThreadLocal, native-виклики, тайм-аути та скасування.
5. Порівняйте пропускну здатність і хвостові затримки з попередньою реалізацією.
6. Впроваджуйте поступово й залиште простий шлях повернення.

Критерій успіху — простіший код за тієї самої надійності

Віртуальні потоки виправдані, коли команда отримує зрозумілу послідовну модель, підтримує більше одночасних очікувань і не погіршує хвостові затримки, пам’ять та керування відмовами. Сам графік із мільйоном створених потоків не є бізнес-результатом. Після міграції код має залишатися дебажним, а ліміти й тайм-аути — очевидними.

Важливо порівнювати не лише синтетичний максимум. Під навантаженням база даних може насититися раніше, а простіший код усе одно зменшить кількість помилок. Рішення приймають за сукупністю продуктивності, операційної складності та здатності команди підтримувати систему.

До релізу потрібен також тест тривалого навантаження. Він виявляє повільне накопичення черг, витоки контексту й залежності, які поводяться добре протягом хвилини, але деградують за кілька годин. Піковий throughput без стабільності не є перевагою.

Першоджерела: JEP 444: Virtual Threads, JEP 491: Synchronize Virtual Threads without Pinning та офіційний посібник Oracle для Java 21.