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