Бэк на JVM: уходить с Kotlin coroutines на Java virtual threads ради простоты?

[rburr]

Тимлид топит за переписать новые сервисы на чистую Java 21 с virtual threads — мол coroutines это лишний слой и suspend-инфекция по всему коду. У нас сейчас Spring + Kotlin coroutines. Кто-то реально мигрировал?

[kernel2025]

Со стороны андроида скажу: structured concurrency и отмена в корутинах это то, чего у loom из коробки нет. Если у вас сложные пайплайны с отменой — потеряете удобство.

[icu2]

Мы держим оба. Virtual threads шикарны для тупого thread-per-request блокирующего кода — старые JDBC драйверы просто заработали без переписывания на reactive. Никаких suspend, никакой раскраски функций.

[kardanger]

Главный подвох loom — pinning. Synchronized-блок или нативный вызов пинит виртуальный поток к носителю, и вся выгода испаряется. Проверьте свои либы профайлером прежде чем радоваться. У нас Hikari пинил пул, искали два дня.

[matguyvr]

senior_burnout вот это полезно, спасибо. В Java 24 вроде synchronized pinning убрали?

[cohenst1]

Да, JDK 24 (JEP 491) сняли pinning на synchronized. Если вы на 21 LTS — ещё актуально, на 24+ полегче.

[Bowden]

По мне так если команда уже знает Kotlin — не трогайте что работает. Миграция ради "меньше слоёв" это переписывание ради переписывания, бизнес спасибо не скажет.

[gdgdgd]

Мигрировал с coroutines на virtual threads в одном сервисе — Spring Boot 3.2, Kotlin. Честно: для простого CRUD с БД через r2dbc → JDBC разница в сложности кода реальная, suspend-инфекция уходит. Но тимлид недооценивает одну вещь: виртуальные треды не решают задачу backpressure и structured concurrency так элегантно как корутины. Если у тебя просто N параллельных HTTP-вызовов — VT хватит. Если цепочки с отменой, таймаутами по поддеревьям, агрегация результатов — coroutines выигрывают по читаемости.

[docker5]

Важный нюанс для Spring + VT: убедись что убрал все blocking-коды из synchronized блоков или заменил на ReentrantLock, иначе получишь pinned threads и весь выигрыш VT испарится. Это не гипотетическая проблема — Hibernate 6.2 и ряд JDBC-драйверов держали synchronized внутри до недавнего времени. Проверяй через -Djdk.tracePinnedThreads=full при нагрузочном тесте перед миграцией.