WebFlux vs Virtual Threads: что происходит при 2000 RPS

Spring WebFlux

Классическая модель Spring MVC работает по принципу «один запрос — один поток». Входящий HTTP-запрос захватывает поток из пула, и этот поток занят на все время обработки, включая ожидание ответов от базы данных и внешних сервисов. Пока поток ждет I/O, он заблокирован и не может обслуживать другие запросы. Масштабирование в такой модели достигается за счет увеличения числа потоков или количества экземпляров приложения. Увеличение числа потоков имеет свои ограничения, так как платформенные потоки ресурс дорогой: каждый поток требует ~1 MB стека, а переключение контекста между ними создает нагрузку на планировщик ОС.

Spring WebFlux предлагает принципиально иной подход, построенный на неблокирующем I/O и модели event loop. Вместо того чтобы выделять поток на каждый запрос, WebFlux обслуживает тысячи одновременных соединений небольшим фиксированным набором потоков. Ключевая идея: поток никогда не блокируется в ожидании I/O, вместо этого он регистрирует интерес к событию (например, «данные прибыли на сокет») и переключается на обработку других готовых задач.

Netty как транспортный уровень

Spring WebFlux по умолчанию использует Reactor Netty — обертку над Netty, предоставляющую Reactive Streams API поверх асинхронного фреймворка. При запуске Spring Boot приложения с зависимостью spring-boot-starter-webflux происходит следующая цепочка инициализации:

1. NettyReactiveWebServerFactory создает экземпляр reactor.netty.http.server.HttpServer.

2. HttpServer конфигурируется через ReactorResourceFactory, которая управляет общими ресурсами — event loop потоками (LoopResources) и пулом соединений (ConnectionProvider).

3. Создается NettyWebServer (org.springframework.boot.reactor.netty.NettyWebServer) — реализация интерфейса Spring Boot WebServer, которая оборачивает HttpServer и ReactorHttpHandlerAdapter (мост между Spring WebFlux HttpHandler и Reactor Netty).

4. При вызове NettyWebServer.start() сервер привязывается к порту и начинает принимать соединения.

EventLoopGroup и EventLoop

Центральная абстракция Netty — io.netty.channel.EventLoopGroup, контейнер для объектов EventLoop. Каждый EventLoop эксклюзивно привязан к одному платформенному потоку. Количество event loop потоков определяется интерфейсом reactor.netty.resources.LoopResources, который по умолчанию использует формулу:

int DEFAULT_IO_WORKER_COUNT = Integer.parseInt(System.getProperty(ReactorNetty.IO_WORKER_COUNT,"" + Math.max(Runtime.getRuntime().availableProcessors(), 4)));

То есть количество потоков равно числу доступных процессоров, но не менее 4. Это значение можно переопределить:

• JVM-параметром -XX:ActiveProcessorCount=N— влияет на Runtime.getRuntime().availableProcessors()

• системным свойством -Dreactor.netty.ioWorkerCount=N— прямое задание количества event loop потоков.

В контейнерной среде (Docker, Kubernetes) JVM определяет число доступных процессоров через cgroups. Если контейнеру выделено 2 CPU — availableProcessors() вернет 2, но поскольку минимум равен 4, будет создано 4 event loop потока. Это поведение можно скорректировать явным указанием -Dreactor.netty.ioWorkerCount=2 для соответствия фактическим ресурсам контейнера.

I/O — мультиплексирование

В основе всей модели лежит способность операционной системы эффективно отслеживать состояние тысяч файловых дескрипторов одним системным вызовом, другими словами, выполнять I/O мультиплексирование. Netty динамически определяет стратегию I/O-мультиплексирования в зависимости от операционной системы, на которой запускается приложение (если в classpath есть соответствующие модули):

• EpollIoHandler — на Linux, модуль netty-transport-native-epoll. Использует нативные системные вызовы epoll_create, epoll_ctl, epoll_wait напрямую через JNI.

• KQueueIoHandler — на macOS, модуль netty-transport-native-kqueue. Использует системные вызовы kqueue/kevent.

• NioIoHandler — fallback-реализация через стандартный Java NIO. На Linux NIO Selector внутри тоже использует epoll, но через прослойку Java NIO, что добавляет небольшой overhead.

Как правило, при создании Docker-образов приложения в качестве базового образа используется тот или иной Linux, поэтому в большинстве случаев мы будем работать именно с EpollIoHandler. Подробнее про механизм epollможно почитать в официальной документации. Именно он позволяет зарегистрировать событие «интереса» на файловом дескрипторе и получить уведомление, когда дескриптор будет готов к работе. Например, поток может зарегистрировать событие ожидания готовности сокета к чтению данных (EPOLLIN) через системный вызов epoll_ctl , после этого в цикле epoll_wait получать уведомления обо всех событиях, которые он ранее зарегистрировал, и, когда для нужного сокета придет уведомление, поток будет знать, что данные гарантированно есть, и можно читать без ожидания.

Channel и Channel affinity

Каждое сетевое соединение в Netty представлено объектом io.netty.channel.Channel. Для TCP-соединений используются конкретные реализации: NioSocketChannel, EpollSocketChannel или KQueueSocketChannel в зависимости от выбранного транспорта.

При приеме нового TCP-соединения серверный Channel (NioServerSocketChannel / EpollServerSocketChannel) вызывает EventLoopGroup.next(), который по своему алгоритму выбирает EventLoop и регистрирует на нем новый клиентский Channel. С этого момента канал навсегда привязан конкретному event loop — все операции с ним (чтение, запись, обработка событий) всегда выполняются в одном и том же потоке. Это фундаментальное свойство называется channel affinity.

Обратная связь при этом асимметрична: один event loop может обслуживать сотни и тысячи каналов, но каждый канал закреплен ровно за одним event loop.

Channel affinity дает два важных преимущества:

1. Отсутствие синхронизации — все операции с каналом гарантированно выполняются в одном потоке, поэтому не требуются блокировки, CAS-операции или volatile-переменные при работе с состоянием конкретного соединения.

2. Эффективность кэша процессора — данные конкретного соединения (буферы, состояние ChannelPipeline) остаются в L1/L2 кэше одного ядра, не мигрируя между ядрами при каждой операции (если не было переключения контекста из-за слишком большого количества EventLoop потоков).

Обработка запроса в ChannelPipeline

Каждый Channel в Netty содержит ChannelPipeline — упорядоченную цепочку обработчиков(ChannelHandler), через которую проходят входящие и исходящие события. Для HTTP-сервера Reactor Netty конфигурирует pipeline следующими обработчиками:

1. io.netty.handler.codec.http.HttpServerCodec — комбинированный кодек, который декодирует входящие байты в объекты HttpRequest и кодирует исходящие HttpResponse в байты.

2. reactor.netty.http.server.HttpTrafficHandler — управляет жизненным циклом HTTP-соединения: keep-alive, pipelining, обработка 100-continue и т.д.

3. reactor.netty.http.server.HttpServerOperations — мост между Netty и Reactor. Реализует интерфейсы HttpServerRequest / HttpServerResponse из Reactor Netty API и связывает Netty-канал с реактивными потоками Reactor.

Далее ReactorHttpHandlerAdapter передает запрос в DispatcherHandler Spring WebFlux, который маршрутизирует его к соответствующему контроллеру. Весь pipeline выполняется в потоке event loop, к которому привязан канал.

Из описанной модели следует главное ограничение: любая блокирующая операция в event loop потоке останавливает обработку всех каналов, привязанных к этому event loop. Если у event loop 500 активных соединений и обработчик одного из них вызвал Thread.sleep(100) или блокирующий JDBC-запрос — все 500 соединений не получают обслуживания в течение всего времени блокировки.

Это не баг, а архитектурное следствие. Модель event loop достигает высокой производительности именно потому, что потоки никогда не блокируются — весь I/O асинхронный, а бизнес-логика выражена через реактивные цепочки, которые не содержат точек блокировки.

Если же в приложении есть блокирующие операции (JDBC, блокирующий HTTP-клиент) или CPU-интенсивные вычисления, их необходимо выносить на отдельный пул потоков, например, через оператор .subscribeOn(Schedulers.boundedElastic()).

Ограничения модели

При всех преимуществах, модель event loop имеет существенные ограничения:

1. Реактивный код на Reactor (цепочки map, flatMap, zip, switchIfEmpty) значительно сложнее для написания и отладки, чем императивный код. Стектрейсы в реактивных приложениях часто нечитаемы — в стеке видны внутренние классы Reactor (FluxMapFuseable, MonoFlatMap), а не бизнес-логика. Для улучшения диагностики можно использовать Hooks.onOperatorDebug(), но это добавляет заметный overhead.

2. Экосистема блокирующих библиотек (JDBC, многие SDK) несовместима с моделью event loop. Для работы с реляционными СУБД необходим R2DBC — реактивный драйвер, набор поддерживаемых СУБД у которого уже, чем у JDBC. Альтернативный подход — вынос блокирующих вызовов на Schedulers.boundedElastic() или Executors.newVirtualThreadPerTaskExecutor().

3. Стандартные инструменты профилирования менее информативны для реактивных приложений: thread dump показывает N event loop потоков, каждый из которых стоит в вызове epoll_wait() / kevent() / Selector.select(), что не дает информации о том, какие именно запросы обрабатываются в данный момент.

4. Одна «тяжелая» операция в event loop (CPU-интенсивный расчет, случайно попавший блокирующий вызов) деградирует не один запрос, а все запросы на этом event loop. При 4 event loop потоках — это потенциально четверть всего трафика приложения.

Virtual Threads

Виртуальные потоки (Project Loom, JEP 444) не меняют модель «один запрос — один поток», они меняют стоимость потока. Каждый запрос по-прежнему получает свой поток, код остается императивным и синхронным, стектрейсы читаемы, ThreadLocal работает. Но теперь «поток» — это легкая Java-конструкция, стоимость которой сравнима с обычным объектом в heap.

Carrier-потоки и планировщик

Виртуальные потоки не исполняются сами по себе — JVM «монтирует» их на платформенные потоки, называемые carrier-потоками. Эти потоки живут в специальном ForkJoinPool, работающем в режиме FIFO, он создается один раз при старте JVM и используется всеми виртуальными потоками.

Количество carrier-потоков определяется свойством jdk.virtualThreadScheduler.parallelism и по умолчанию равно числу доступных процессоров (Runtime.getRuntime().availableProcessors()). В контейнере с 2 CPU это означает всего 2 carrier-потока — и именно на этих 2 платформенных потоках могут поочередно исполняться тысячи виртуальных.

Метод создания планировщика по умолчанию в классе VirtualThread.java.

private static ForkJoinPool createDefaultScheduler() {    ForkJoinWorkerThreadFactory factory = pool -> new CarrierThread(pool);    int parallelism, maxPoolSize, minRunnable;    String parallelismValue = System.getProperty("jdk.virtualThreadScheduler.parallelism");    String maxPoolSizeValue = System.getProperty("jdk.virtualThreadScheduler.maxPoolSize");    String minRunnableValue = System.getProperty("jdk.virtualThreadScheduler.minRunnable");    if (parallelismValue != null) {        parallelism = Integer.parseInt(parallelismValue);    } else {        parallelism = Runtime.getRuntime().availableProcessors();    }    if (maxPoolSizeValue != null) {        maxPoolSize = Integer.parseInt(maxPoolSizeValue);        parallelism = Integer.min(parallelism, maxPoolSize);    } else {        maxPoolSize = Integer.max(parallelism, 256);    }    if (minRunnableValue != null) {        minRunnable = Integer.parseInt(minRunnableValue);    } else {        minRunnable = Integer.max(parallelism / 2, 1);    }    Thread.UncaughtExceptionHandler handler = (t, e) -> { };    boolean asyncMode = true; // FIFO    return new ForkJoinPool(parallelism, factory, handler, asyncMode,                 0, maxPoolSize, minRunnable, pool -> true, 30, SECONDS);}

Как это возможно? Благодаря механизму mount/unmount.

Когда виртуальный поток готов к работе, планировщик монтирует его на свободный carrier-поток: восстанавливает стек вызовов из heap и передает управление. С этого момента carrier-поток исполняет код виртуального потока — проходит через фильтры, контроллер, сервисный слой — точно так же, как обычный платформенный поток.

Самое интересное происходит, когда код доходит до блокирующей операции, скажем, repository.findById(id) , и ждет ответа от БД. В этот момент JVM выполняет unmount:

1. Стек вызовов виртуального потока сохраняется в объекты StackChunk в Java heap.

2. Виртуальный поток переходит в состояние PARKED.

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

С точки зрения бизнес-кода ничего не произошло — repository.findById(id) просто еще не вернул результат. Но carrier-поток уже обслуживает другой запрос.

Когда данные от БД прибудут, виртуальный поток будет «разбужен» и поставлен обратно в очередь планировщика. При следующей возможности (возможно, на другом carrier-потоке) стек восстановится из heap, и исполнение продолжится ровно с того места, где остановилось.

За время обработки одного HTTP-запроса, включающего вызов внешнего сервиса и запрос к БД, виртуальный поток может пройти через несколько циклов mount/unmount, каждый раз освобождая carrier для другой работы.

JVM Poller — под капотом виртуальных потоков

Остается вопрос: кто «будит» виртуальный поток, когда данные на сокете готовы?

Этим занимается Poller — механизм, подробно описанный в статье Networking I/O with Virtual Threads — Under the hood. Он работает следующим образом: когда виртуальный поток делает блокирующий вызов, скажем, socket.read(), и данные еще не готовы, JVM переводит нативный сокет в неблокирующий режим и регистрирует его файловый дескриптор в Poller’е. Стоит уточнить, что сокет переводится в неблокирующий режим один раз, при первом вызове из виртуального потока, а не каждый раз.

JVM создает два выделенных платформенных потока:

• Read-Poller — отслеживает готовность к чтению, connect и accept.

• Write-Poller — отслеживает готовность к записи.

Каждый из них крутит цикл с вызовом I/O-мультиплексора ОС — того же самого, что использует Netty:

• На Linux — EPollPoller, вызывающий epoll_wait().

• На macOS — KQueuePoller, вызывающий kevent().

Когда ОС сообщает, что на сокете появились данные, Poller вызывает VirtualThread.unpark() — виртуальный поток ставится в очередь ForkJoinPool и при следующей возможности монтируется на carrier-поток.

По сути, виртуальные потоки и WebFlux используют один и тот же механизм ОС (epoll/kqueue) для отслеживания готовности I/O, но на разных уровнях абстракции. Netty работает с epoll напрямую в event-loop потоке, а виртуальные потоки — через промежуточный слой Poller.

Нюансы настройки

Параметр parallelism, пожалуй, один из наиболее важных для тюнинга работы сервисов на виртуальных потоках в Docker/Kubernetes. По умолчанию он равен числу CPU из cgroups. Для контейнера с 2 CPU — parallelism=2, то есть всего 2 carrier-потока. Казалось бы, для I/O-bound приложения 2 потока достаточно: виртуальные потоки ведь размонтируются при I/O. Но между блокирующими вызовами есть участки CPU-работы: парсинг JSON, маппинг объектов, валидация, и 2 carrier-потока становятся узким местом. Дополнительные потоки обеспечивают более быстрый подхват виртуальных потоков из очереди. Но при значительном превышении числа ядер overhead от переключений контекста планировщиком ОС начинает доминировать.

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

• Компенсация. Некоторые операции блокируют carrier-поток, но JDK знает об этом и создает дополнительный компенсационный carrier-поток для поддержания параллелизма. Примеры: файловый I/O, Object.wait(). Максимальное число таких компенсационных потоков ограничено параметром jdk.virtualThreadScheduler.maxPoolSize (по умолчанию 256). Компенсационные потоки живут 30 секунд после создания, даже если больше не нужны.

• Pinning. Виртуальный поток «прикреплен» к carrier-потоку и не может размонтироваться, например, при исполнении нативного кода или foreign functions. До JDK 24 аналогичная проблема существовала для synchronized-блоков (JEP 491 устранил это). Критически важно: планировщик не компенсирует pinning. Если виртуальный поток «прикрепился» (pinned) к carrier-потоку, фактический параллелизм снижается, и все остальные виртуальные потоки ждут в очереди.

Потребление ресурсов

Виртуальные потоки дешевле платформенных, но не бесплатны. Два аспекта, за которыми стоит следить:

• Стек каждого виртуального потока хранится в объектах StackChunk в Java heap. При глубоком стеке (а стек Spring MVC запроса проходит через десятки фреймов: Tomcat, фильтры, Spring, Hibernate, JDBC) каждый виртуальный поток может потреблять десятки килобайт heap. При тысячах одновременных VT это создает ощутимое давление на GC. Стоит уточнить: это оценка для парковки, когда стек сохранен в StackChunk. Пока виртуальный поток смонтирован на carrier, его стек находится на нативном стеке carrier-потока и отдельного потребления heap не создает.

• Каждый виртуальный поток имеет собственный ThreadLocalMap. При тысячах VT объем ThreadLocal-данных может быть значительным, особенно с учетом Spring Security context, MDC, Micrometer observation context.

Включение в Spring Boot

Начиная с Spring Boot 3.2, достаточно одной строки:

spring:  threads:    virtual:      enabled: true

В этом случае Spring Boot активирует TomcatVirtualThreadsWebServerFactoryCustomizer, который настраивает ProtocolHandlerTomcat-а на использование VirtualThreadExecutor. Вместо извлечения потока из фиксированного пула Tomcat теперь создает новый виртуальный поток на каждый входящий запрос. Соответственно, все настройки размера пула потоков Tomcat уже не будут действовать. Помимо обработки HTTP-запросов, это свойство переключает на виртуальные потоки @Async-методы и TaskScheduler.

Более подробно о работе с виртуальными потоками и нюансами профилирования можно почитать в статье Java’s Concurrency Revolution: How Immutability and Virtual Threads Changed Everything!