Что проверяет вопрос про @ConditionalOnMissingBean

@ConditionalOnMissingBean позволяет автоконфигурации Spring Boot создать бин по умолчанию только тогда, когда разработчик не определил свой. Вопрос проверяет, понимаете ли вы, что условие проверяется не по коду, а по фактическому состоянию BeanFactory в момент обработки конфигурации — то есть зависит от порядка, в котором Spring обрабатывает классы @Configuration.

Порядок критичен, когда несколько автоконфигураций претендуют на один и тот же тип бина. Spring Boot управляет порядком через @AutoConfigureOrder, @AutoConfigureBefore и @AutoConfigureAfter. Если порядок не задан явно, какая автоконфигурация «застолбит» бин первой — деталь реализации, а не контракт, и она может измениться между версиями Boot.

Пользовательские @Configuration-классы приложения по умолчанию обрабатываются раньше автоконфигураций библиотек — поэтому в большинстве случаев ваш собственный бин выигрывает без дополнительных условий с вашей стороны.

Спросят следом: чем @ConditionalOnMissingBean отличается от @ConditionalOnBean, и сработает ли проверка, если в контексте уже есть бин того же типа, но с другим именем. Ответ: по умолчанию condition matching идёт по типу через ResolvableType, имя роли не играет, если явно не указано уточнение.

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

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки