Привет, Хабр !

В первой части я разобрал, как с конкурентностью работает Java: обычные Thread, thread pools, virtual threads и structured concurrency. Теперь пришло время нырнуть в кроличью нору и узнать, что есть мир за пределами стандартной Java.

Рассмотрим три разных подхода:

1. Kotlin coroutines.

2. ZIO runtime в Scala.

3. Clojure с его immutable data, STM и agents.

Это не попытка выбрать победителя. Kotlin, ZIO и Clojure решают разные задачи: где-то их подходы пересекаются, а где-то расходятся почти полностью.

5. Kotlin coroutines

Начнём с Kotlin.

Kotlin coroutines решают ту же боль, что и Loom: хочется писать нормальный последовательный код и не держать реальный поток там, где программа просто ждёт. Но путь другой.

Корутина - это не Thread. Это приостанавливаемое вычисление. Kotlin-компилятор превращает suspend-функции в state machine. В точке приостановки состояние сохраняется, поток освобождается, а потом выполнение продолжается через continuation.

suspend fun handleRequest(userId: UserId): Response {
    val user = loadUser(userId)
    val orders = loadOrders(userId)
    return render(user, orders)
}

На вид обычный последовательный код. Но loadUser и loadOrders могут быть неблокирующими suspend-операциями. Поток при этом не обязан стоять и ждать.

Параллелизм в Kotlin обычно выглядит так:

suspend fun handleRequest(userId: UserId): Response = coroutineScope {
    val user = async { loadUser(userId) }
    val orders = async { loadOrders(userId) }

    render(user.await(), orders.await())
}

coroutineScope здесь нужен не для красоты. Он управляет жизнью дочерних корутин. Если одна корутина упадёт, scope отменит остальные. Если родитель отменён, дочерние тоже не должны жить своей отдельной жизнью.

Тут та же мысль, что и в Java Structured Concurrency: задача не должна бесконтрольно улетать в фон и жить отдельно от родительского запроса. В Kotlin эта идея давно встроена в обычную модель программирования, а не вынесена в отдельный preview API.

Dispatcher

Корутина сама по себе не равна потоку. Ей нужен dispatcher:

Dispatchers.Default - CPU-bound
Dispatchers.IO      - blocking I/O
Dispatchers.Main    - UI thread

И вот здесь часто начинается путаница. Kotlin coroutines не делают blocking-код автоматически неблокирующим. Если внутри корутины вызвать старый blocking JDBC и не вынести его на правильный dispatcher, реальный поток будет заблокирован.

Знакомо? Код выглядит асинхронно, suspend на месте, а thread dump всё равно показывает ожидание JDBC.

suspend fun loadUser(userId: UserId): User =
    withContext(Dispatchers.IO) {
        blockingUserRepository.loadUser(userId)
    }

Корутины дают красивую модель suspend-кода, cancellation и structured concurrency. Но старый blocking JDBC внутри корутины всё равно остаётся старым blocking JDBC. Это место легко пропустить, особенно когда код выглядит таким аккуратным.

Как Kotlin coroutines относятся к virtual threads

Если уж совсем коротко:

Virtual threads: обычный blocking-код, дешёвые Thread на уровне JVM.
Kotlin coroutines: suspend-функции, continuation, dispatcher, structured concurrency на уровне языка и библиотеки.

Virtual threads сохраняют Java-стиль. Метод остаётся обычным методом:

User loadUser(UserId userId) {
    return userRepository.loadUser(userId);
}

Kotlin явно помечает приостанавливаемость:

suspend fun loadUser(userId: UserId): User {
    return userRepository.loadUser(userId)
}

Разница практическая. suspend-функцию нельзя просто вызвать из любого места. Нужен coroutine context. Зато компилятор и библиотека дают встроенную модель cancellation и structured concurrency.

Java с virtual threads говорит: “оставьте blocking-код как есть, мы сделаем ожидание дешёвым”.

Kotlin говорит: “пишите suspend-код, а runtime будет приостанавливать и продолжать вычисления”.

Loom делает потоки дешевле, а Kotlin меняет сам способ описывать приостанавливаемое выполнение через suspend-функции.

6. ZIO runtime

Перед ZIO надо сделать маленькое отступление. Иначе слово “effect” выглядит как термин из секты функциональных программистов, которые опять придумали новое название для обычного вызова метода.

Эффект - это действие, которое не сводится к чистому вычислению значения. Например:

• сходить в базу;

• отправить HTTP-запрос;

• прочитать файл;

• записать лог;

• получить текущее время;

• сгенерировать случайное число;

• упасть с ошибкой;

• запустить параллельную задачу.

Чистая функция в математическом смысле скучная, но удобная: на один и тот же вход всегда один и тот же выход, без сюрпризов снаружи.

def discount(price: BigDecimal, percent: Int): BigDecimal =
  price * (100 - percent) / 100

А вот это уже effectful-код:

def loadUser(id: UserId): User =
  jdbc.query("select * from users where id = ?", id)

Сигнатура говорит: “верну User”. Но на самом деле внутри ещё целый набор событий: поход в сеть или БД, ожидание, возможный timeout, ошибка соединения, занятый connection pool, retry на уровне драйвера.

В типе этого почти не видно. Для Java это привычно: метод что-то делает, а мы уже по названию, документации и опыту догадываемся, насколько это опасно.

Функциональные effect-библиотеки пытаются сделать такие действия явными. Не выполнить прямо сейчас, а описать как значение:

val loadUser: ZIO[UserRepo, DomainError, User] =
  ZIO.serviceWithZIO[UserRepo](_.load(userId))

Тут важный сдвиг в голове: effectful-программа становится не набором немедленных действий, а описанием действий. Это описание можно комбинировать, передавать, тестировать, повторять, отменять и только потом исполнять runtime’ом.

ZIO в Scala похож на корутины только издалека. Там тоже есть lightweight-задачи: fibers. Но ZIO начинается не с “как запустить async”, а с идеи: эффектная программа должна быть значением.

Тип:

ZIO[R, E, A]

Расшифровка:

• R: какие зависимости нужны программе;

• E: с какой ошибкой она может завершиться;

• A: какой результат вернёт.

val program: ZIO[UserRepo & OrderClient, DomainError, Response] =
  for {
    user   <- loadUser(userId)
    orders <- loadOrders(userId)
  } yield render(user, orders)

Это ещё не выполнение. Это описание. Runtime потом исполняет его на fibers.

ZIO fiber - лёгкая задача внутри ZIO runtime. Она умеет interruption, supervision, fiber-local state, retry, scheduling, resource safety, structured concurrency. И всё это не как набор случайных утилит, а как часть единой модели.

Параллелизм:

val handle: ZIO[UserRepo & OrderClient, DomainError, Response] =
  loadUser(userId).zipPar(loadOrders(userId)).map { case (user, orders) =>
    render(user, orders)
  }

Работа с ресурсом:

val useConnection: ZIO[Any, Throwable, Result] =
  ZIO.acquireRelease(openConnection)(conn => closeConnection(conn).orDie) { conn =>
    runQuery(conn)
  }

Для человека из Java это может выглядеть как “слишком функционально”. Но идея мощная: ошибки, зависимости, ресурсы, отмена и параллелизм становятся частью типа и композиции.

Как ZIO относится к virtual threads

ZIO не обязан “переезжать” на virtual threads, потому что у него уже есть fibers и свой runtime.

Virtual thread остаётся Thread: JVM делает его дешёвым и удобным для blocking-style Java. ZIO fiber живёт на другом уровне: он исполняет ZIO[R, E, A], где рядом с параллелизмом уже есть interruption, supervision, scopes, resource safety, типизированная ошибка и зависимости.

Virtual threads могут быть полезны ZIO как interop-слой для legacy blocking Java-кода. Например, если внутри эффекта вызывается старый Java-клиент, который блокирует поток. Но заменой ZIO runtime они не становятся.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var user = executor.submit(() -> loadUser(userId));
    var orders = executor.submit(() -> loadOrders(userId));
    return render(user.get(), orders.get());
}

loadUser(userId).zipPar(loadOrders(userId)).map { case (user, orders) =>
  render(user, orders)
}

В Java мы управляем задачами. В ZIO мы комбинируем описания эффектов. Разница кажется философской, пока не появляются отмена, ретраи, ресурсы, typed errors и тестирование.

Virtual threads делают обычную Java-конкурентность дешевле. ZIO решает более широкую задачу: как описывать concurrent/effectful-программу целиком.

7. Clojure: immutable state, STM, agents и JVM threads

Clojure на фоне Java, Kotlin и Scala/ZIO стоит немного боком. В хорошем смысле.

В Java центр тяжести - Thread, ExecutorService, virtual threads и structured concurrency. В Kotlin - suspend, coroutine scope и dispatcher. В ZIO - effect runtime и fibers.

Clojure начинает не с вопроса “как запустить побольше задач?”. Он начинает с вопроса “а зачем вы вообще шарите изменяемое состояние между потоками?”.

Данные в Clojure по умолчанию immutable. Persistent data structures позволяют дёшево создавать новые версии коллекций, не меняя старые. Часть классических проблем конкурентности после этого просто не появляется.

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

А там, где состояние всё-таки нужно менять, Clojure предлагает несколько разных примитивов:

atom   - независимое синхронное состояние, update через compare-and-swap
ref    - координированное состояние через STM-транзакции
agent  - асинхронное изменение состояния через очередь действий
var    - динамические bindings и глобальные значения
promise/future/delay - простые примитивы отложенного и параллельного вычисления

Clojure не говорит: “вот вам корутины, теперь всё решайте через них”. Скорее так: сначала уберите shared mutable state, а для оставшейся мутабельности возьмите подходящий coordination primitive.

(def counter (atom 0))

(swap! counter inc)
(swap! counter + 10)

@counter

atom хорошо подходит для одного независимого значения. swap! применяет функцию к текущему состоянию и обновляет значение атомарно. Важно, что функция может быть вызвана больше одного раза из-за CAS-retry, поэтому внутри неё не должно быть побочных эффектов.

Если надо согласованно менять несколько значений, появляется ref и STM.

(def account-a (ref 100))
(def account-b (ref 50))

(defn transfer [amount]
  (dosync
    (alter account-a - amount)
    (alter account-b + amount)))

STM - Software Transactional Memory. Для Java-разработчика это выглядит непривычно: транзакция не в базе, а в памяти процесса. Несколько ref можно менять внутри dosync как одну согласованную операцию. При конфликте транзакция может быть повторена.

Это не замена транзакциям в БД и не магическое распределённое состояние. Но внутри одного JVM-процесса это очень сильная модель для координации shared state.

Как Clojure ложится на JVM threads и на virtual threads

Clojure - обычный JVM-язык. Его функции исполняются на обычных JVM-потоках. Thread, ExecutorService, ForkJoinPool, CompletableFuture, virtual threads - всё доступно через Java interop.

Базовые примитивы Clojure тоже в итоге ложатся на JVM-механизмы:

• future запускает вычисление в пуле потоков;

• promise даёт значение, которое кто-то позже доставит через deliver;

• agent хранит состояние и применяет к нему отправленные функции асинхронно;

• send для agents рассчитан на CPU-bound действия;

• send-off исторически используют для potentially blocking действий.

Так как Clojure работает на JVM, virtual threads доступны ему напрямую. Можно создать virtual thread из Clojure так же, как из Java:

(Thread/startVirtualThread
  (fn []
    (let [user   (load-user user-id)
          orders (load-orders user-id)]
      (render user orders))))

Или использовать Java executor:

(with-open [executor (java.util.concurrent.Executors/newVirtualThreadPerTaskExecutor)]
  (let [user   (.submit executor #(load-user user-id))
        orders (.submit executor #(load-orders user-id))]
    (render (.get user) (.get orders))))

Тут легко попасть в ловушку. Core-примитивы Clojure не становятся автоматически “виртуально-поточными”. Если вы пишете (future ...), это не означает “создай virtual thread”. Если вы используете agents, их executor тоже не превращается сам по себе в Loom runtime.

Я бы запомнил это вот так:

Clojure + virtual threads = можно писать обычный blocking JVM-код и запускать его на Loom.
Clojure core futures/agents = по умолчанию своя историческая модель поверх executor'ов.

Для Clojure backend на JDBC, HTTP-клиентах и обычных blocking Java-библиотеках virtual threads могут быть очень естественным улучшением. Clojure-функции не требуют специального suspend, поэтому blocking-style код хорошо ложится на Loom. Но надо явно выбрать executor, сервер или runtime, который использует virtual threads.

Вывод

Kotlin coroutines, ZIO fibers и Clojure futures/agents похожи только издалека. Каждый из этих подходов по-своему решает задачи конкурентности и делает акцент на разных вещах.

Kotlin выносит асинхронность в модель suspend-функций: вместе с ней появляются coroutine context, dispatcher, cancellation и structured concurrency на уровне языка и библиотеки.

ZIO идёт дальше в сторону effect system: программа становится значением ZIO[R, E, A], а runtime уже исполняет это описание на fibers и тащит рядом ошибки, зависимости, ресурсы, отмену и параллелизм.

Clojure начинает с другого конца: сначала immutable data и отказ от shared mutable state, а уже потом atoms, refs, agents, futures и Java interop там, где они действительно нужны.

Virtual threads после этого не становятся “заменой всему”. В Java они делают поток достаточно дешёвым, чтобы снова спокойно писать блокирующий код. Для Kotlin, ZIO и Clojure это скорее ещё один инструмент рядом с уже существующими моделями.

В третьей части останется самое вкусное: сравнение Kotlin coroutines с ZIO, Clojure core.async, ZIO-like библиотеки и вопрос, есть ли вообще ZIO-аналог в чистой Java.

Если вам близки темы разработки, рефакторинга, архитектуры и стартапов, буду рад видеть вас в моём Telegram-канале.