Бины Spring: цикл и скоупы

class Holder {
    @Autowired Proto injectedField;            // prototype полем
    @Autowired ObjectProvider<Proto> provider; // он же через провайдера
}

// обращение 1: поле -> Proto#1,  провайдер -> Proto#2
// обращение 2: поле -> Proto#1,  провайдер -> Proto#3
// обращение 3: поле -> Proto#1,  провайдер -> Proto#4

@Service
class Orders {
    @Transactional void save(Order o) { ... }

    void batch(List<Order> os) {
        for (Order o : os) this.save(o);   // мимо прокси
    }
}

// вызов снаружи:  BEGIN ... COMMIT
// вызов через this: в логе пусто

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #bean_lifecycle_scopes1 / 5
   Потокобезопасен ли singleton-бин Spring по умолчанию?

   A)Да, Spring автоматически синхронизирует все методы singleton-бина, поэтому гонок в нём встречается редко

   B)Нет — один экземпляр делят все потоки; за потокобезопасность отвечает разработчик

   C)Да, потому что каждый поток при обращении получает свою отдельную копию singleton-бина из контейнера

   D)Вопрос неприменим: singleton-бины в Spring не вызываются из нескольких потоков сразу

   показать ответ и разбор

   +B)Нет — один экземпляр делят все потоки; за потокобезопасность отвечает разработчик

   // разбор: Spring-скоуп singleton != потокобезопасность. Это ОДИН экземпляр, разделяемый ВСЕМИ потоками (веб-запросы обслуживаются параллельно). Spring ничего не синхронизирует автоматически. Поэтому если в singleton-бине хранить изменяемое состояние (поля, меняющиеся между запросами), возникнут гонки. Правильный дизайн — делать сервисы БЕЗ СОСТОЯНИЯ (stateless): всё нужное передавать в параметрах/локальных переменных. Изменяемое состояние на запрос — в request-scope бинах или локально, а не в полях синглтона.

2. #bean_lifecycle_scopes2 / 5
   Когда используют scope prototype?

   A)Когда бин должен существовать в одном экземпляре и переиспользоваться во всём приложении

   B)Когда бин обслуживает ровно один HTTP-запрос и уничтожается по его завершении контейнером

   C)Когда нужен новый экземпляр бина на каждое получение/внедрение

   D)Когда бин обязан создаваться заранее при старте контейнера, ещё до первого обращения к нему

   показать ответ и разбор

   +C)Когда нужен новый экземпляр бина на каждое получение/внедрение

   // разбор: prototype-бин контейнер создаёт ЗАНОВО при каждом получении (getBean/внедрении). Подходит для объектов с состоянием, которые нельзя разделять, или для короткоживущих сущностей. Нюанс: для prototype контейнер НЕ управляет полным жизненным циклом — не вызывает destroy-колбэки (за очистку отвечает получатель). И осторожно с внедрением prototype в singleton: по умолчанию внедрится ОДИН экземпляр на всё время жизни синглтона (нужен ObjectProvider/@Lookup/scoped proxy, чтобы получать свежий).

3. #bean_lifecycle_scopes3 / 5
   Что делают @PostConstruct и @PreDestroy?

   A)Создают и удаляют бин: @PostConstruct вызывает конструктор, а @PreDestroy освобождает память объекта

   B)Помечают методы, которые контейнер выполняет на КАЖДЫЙ вызов бина — до и после основной логики метода

   C)Задают порядок создания бинов: @PostConstruct-бины создаются последними, @PreDestroy — первыми

   D)Колбэки жизненного цикла: после внедрения зависимостей и перед уничтожением бина

   показать ответ и разбор

   +D)Колбэки жизненного цикла: после внедрения зависимостей и перед уничтожением бина

   // разбор: @PostConstruct — метод, который контейнер вызывает ОДИН раз ПОСЛЕ создания бина и внедрения всех зависимостей (конструктор уже отработал, но там зависимости ещё не гарантированы) — для инициализации. @PreDestroy — метод, вызываемый перед уничтожением бина при закрытии контекста — для освобождения ресурсов (закрыть пул, остановить поток). Это часть lifecycle-колбэков (наряду с InitializingBean/DisposableBean и init/destroy-методами @Bean). Для prototype @PreDestroy НЕ вызывается.

4. #bean_lifecycle_scopes4 / 5
   Чем @Bean-метод в @Configuration отличается от @Component?

   A)@Bean регистрирует объект программно в конфиг-классе (для чужих/сложных классов); @Component — сканированием

   B)@Bean и @Component взаимоисключающи: класс с @Bean-методом не получится одновременно помечать @Configuration

   C)@Component создаёт prototype-бины, а @Bean — только singleton, в этом их основное различие

   D)@Bean работает только для интерфейсов, а @Component — только для конкретных реализующих их классов

   показать ответ и разбор

   +A)@Bean регистрирует объект программно в конфиг-классе (для чужих/сложных классов); @Component — сканированием

   // разбор: @Component вешают на СВОЙ класс, и component scan сам регистрирует его как бин. @Bean — метод в @Configuration-классе, который ЯВНО создаёт и возвращает объект-бин; так регистрируют то, что нельзя пометить аннотацией: классы из СТОРОННИХ библиотек, объекты со сложной сборкой/настройкой, несколько бинов одного типа. Важно: @Configuration проксируется (CGLIB), поэтому повторный вызов @Bean-метода изнутри вернёт ТОТ ЖЕ синглтон, а не новый объект. Оба подхода дают бины контейнера.

5. #bean_lifecycle_scopes5 / 5
   Когда бин со scope singleton создаётся в ApplicationContext по умолчанию?

   A)Лениво, только при первом обращении к нему из кода, чтобы ускорить старт приложения по умолчанию

   B)Заранее (eager), при инициализации контекста на старте приложения

   C)При каждом обращении заново, но результат кэшируется в контейнере до перезапуска приложения

   D)Автоматически не создаётся: singleton-бины нужно создавать вручную вызовом context.createBean()

   показать ответ и разбор

   +B)Заранее (eager), при инициализации контекста на старте приложения

   // разбор: ApplicationContext по умолчанию создаёт все singleton-бины ЗАРАНЕЕ (eager), при старте контекста. Плюс: ошибки конфигурации (нет зависимости, циклы, падение @PostConstruct) обнаруживаются НЕМЕДЛЕННО, а не при первом запросе в проде. Ленивую инициализацию включают точечно @Lazy (или глобально spring.main.lazy-initialization) — она ускоряет старт, но откладывает проявление ошибок. prototype же всегда создаётся по требованию. По умолчанию «fail fast» на старте предпочитают отложенным сюрпризам.