В чем разница создания Mono через just и через Callable в Spring WebFlux

Что проверяют

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

Как отвечать

• Mono.just(value): жадный. Аргумент вычисляется сразу, как только Java дошла до выражения, до всякой подписки. Mono.just(repository.findById(id)) сходит в базу, даже если на Mono никто не подпишется, а каждый подписчик получит одно и то же заранее посчитанное значение. Mono.just(null) бросит NullPointerException, для nullable есть Mono.justOrEmpty;
• Mono.fromCallable(callable): ленивый. Callable вызывается заново при каждой подписке. Исключение, даже проверяемое, превращается в сигнал onError, и его ловят onErrorResume или onErrorReturn. Если вернулся null, Mono завершится пустым;
• поток выполнения: fromCallable сам по себе не асинхронный. Код выполнится там, где произошла подписка, в WebFlux это event loop Netty. Блокирующий вызов уводят явно: Mono.fromCallable(() -> jdbc.query(...)).subscribeOn(Schedulers.boundedElastic());
• родственники: Mono.fromSupplier то же без проверяемых исключений, Mono.defer(() -> Mono.just(compute())) откладывает сборку целого Mono.

Короткое правило: just для готового значения или константы, fromCallable для дорогого вычисления, побочного эффекта или кода, который может бросить исключение.

Где спотыкаются

Пишут Mono.just(blockingCall()) и считают код реактивным. Вызов блокирует поток при сборке, а его исключение вылетит мимо цепочки, и onErrorResume его не увидит.

Думают, что fromCallable сам уходит в фоновый поток. Без subscribeOn блокирующий вызов займёт поток event loop, и под нагрузкой сервис встанет.

Ждут от just нового вычисления при повторной подписке, например в retry(). Повтор получит то же значение, для настоящего повтора нужен fromCallable или defer.