WebFlux часто вызывает путаницу, потому что его обычно объясняют со стороны инструмента, а не со стороны проблемы.

Поэтому начнем с базы.

Сначала: блокирующий vs неблокирующий код

-» Блокирующий код:
Поток встает и ждет, пока операция не завершится.
Пока ждет, он ничего больше делать не может.

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

Это не быстрее.
Это просто более эффективное использование потоков.

Еще одно ключевое понятие перед тем как идти дальше:

Backpressure. Это способность системы регулировать поток данных, чтобы не перегружать потребителя.

Представь так:
потребитель может сказать продюсеру: «присылай только столько, сколько я успеваю обработать».

Теперь к WebFlux.

WebFlux позволяет строить полностью неблокирующие приложения end-to-end:

-»Неблокирующий сервер (Netty)
-»Неблокирующие API
-»Проброс backpressure без перегрузки потребителя
-»Реактивная модель (Mono, Flux)

Ключевое слово здесь end-to-end.
Если хотя бы одна часть блокирует, весь выигрыш размывается.

Самая частая ошибка при работе с WebFlux

Использовать WebFlux, а потом:

-»Дернуть блокирующую базу данных
-»Использовать SDK без реактивной поддержки
-»Делать .block(), потому что так проще

В итоге:

-»Все равно все становится блокирующим
-»Ты просто добавил сложности
-»Ничего не выиграл

WebFlux не превращает блокирующий код в неблокирующий.

А Virtual Threads разве это не меняют?

Меняют, и это важно.

С Virtual Threads:

-»Блокирующая модель снова становится жизнеспособной
-»Цена ожидания резко падает
-»Необходимость в WebFlux уменьшается

Но есть нюанс.

Virtual Threads не дают:

-»Backpressure
-»Контроль потока
-»Композицию стримов
-»Настоящий стриминг данных

Они меняют tradeoff, но не убирают саму проблему.

Когда WebFlux все еще имеет смысл

WebFlux оправдан, когда:

-»Нужен реальный backpressure
-»Ты работаешь с непрерывными стримами (SSE, WebSockets)
-»Есть fan-out из множества внешних вызовов
-»Нужно явно контролировать поток данных

По необходимости, а не потому что модно.

Когда не стоит использовать WebFlux

-»Классический CRUD
-»Сложная бизнес-логика
-»Команды без реактивного опыта
-»Проекты, где читаемость важнее конкурентности
-»Когда Virtual Threads решают задачу с меньшей когнитивной стоимостью

WebFlux это другая модель исполнения.

Если твоя проблема не в масштабной I/O-конкурентности,
WebFlux тебе не поможет.

А сегодня, с Virtual Threads, многим он уже просто не нужен.

👉 Java Portal