Расскажите что такое spring bean опишите жизненный цикл spring bean

Подготовка к Spring Professional Certification. Контейнер, IoC, бины

Доброго времени суток, Хабр.

Сегодня я решил представить вам перевод цикла статей для подготовки к Spring Professional Certification.

Это перевод только первой статьи, если он зайдет аудитории, я продолжу выпуск переводов.

Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами. Таким образом, при применении DI, ваш код становится чище, проще, его становится легче понять и тестировать.
Согласно паттерну DI, создание объектов для зависимостей переходит на фабрику или отдается третьей стороне. Это означает, что мы можем сосредоточиться на использовании этих объектов вместо их создания.

В Spring Framework интерфейс org.springframework.factory.BeanFactory предоставляет фабрику для бинов, которая в то же время является IoC контейнером приложения. Управление бинами основано на конфигурации(java или xml).

Интерфейс org.springframework.context.ApplicationContext — это обертка над bean factory, предоставляющая некоторые дополнительные возможности, например AOP, транзакции, безопасность, i18n, и т.п.

Основа Spring Framework — контейнер, и наши объекты «живут» в этом контейнере.
Контейнер обычно создает множество объектов на основе их конфигураций и управляет их жизненным циклом от создания объекта до уничтожения.

Контейнер — это объект, реализующий интерфейс ApplicationContext.

Spring обеспечивает несколько разновидностей контекста.

Есть несколько основных реализаций интерфейса ApplicationContext:

Примеры создания контекста:

Если вы используете JUnit 5, то вам нужно указать 2 аннотации:

Если это не веб-приложение, то есть 2 способа:

В Spring Boot приложении:

Этот класс поместит в контейнер экземпляр класса DataSource. Позднее его можно будет использовать при доступе к базе данных.

Component scanning(сканирование компонентов) — Spring автоматически обнаруживает бины, которые будут находиться в контейнере. Это бины с аннотациями-стереотипами.

Область видимости — scope, скоуп. Существует 2 области видимости по умолчанию.

И 4 области видимости в веб-приложении.

Область видимости указывается с помощью аннотации @Scope на @Bean методах.

Prototype Scope не потокбезопасный, т.к. он не гарантирует что один и тот же экземпляр будет вызываться только в 1 потоке.

Singleton Scope же наоборот потокобезопасный.

Singleton-бины обычно создаются сразу при сканировании.
Prototype-бины обычно создаются только после запроса.

Singleton bean можно внедрять в любой другой бин.

Prototype может быть зависимостью для любого бина.
Внедрять можно только singleton или prototype.

Для того чтобы использовать кастомный BFPP. Вы можете переопределить механизм получения данных из метафайлов.

Есть 3 варианта для создания таких методов:

Ниже перечислены типы DI, которые могут быть использованы в вашем приложении:

DI через конструктор считается самым лучшим способом, т.к. для него не надо использовать рефлексию, а также он не имеет недостатков DI через сеттер.
DI через поле не рекомендуется использовать, т.к. для этого применяется рефлексия, снижающая производительность.
DI через конструктор может приводить к циклическим зависимостям. Чтобы этого избежать, можно использовать ленивую инициализацию бинов или DI через сеттер.

Контейнер обрабатывает DI с помощью AutowiredAnnotationBeanPostProcessor. В связи с этим, аннотация не может быть использована ни в одном BeanFactoryPP или BeanPP.

Если внедряемый объект массив, коллекция, или map с дженериком, то Spring внедрит все бины подходящие по типу в этот массив(или другую структуру данных). В случае с map ключом будет имя бина.

Вы можете использовать разные типы внедрения:

Spring предоставляет аннотацию Qualifier, чтобы преодолеть проблему неоднозначности при DI.

Если в контейнере есть несколько бинов одного типа(SomeClass), то контейнер внедрит именно тот бин, над @Bean-методом которого стоит соответствующий квалификатор. Также можно не ставить квалификатор на метод, а использовать имя бина в качестве параметра квалификатора.
Имя бина можно можно указать через параметр аннотации Bean, а по умолчанию это имя фабричного метода.

Прокси это специальный объект, который имеет такие же публичные методы как и бин, но у которого есть дополнительная функциональность.
Два вида прокси:

Если в контейнере нет экземпляра бина, то вызывается @Bean-метод. Если экземпляр бина есть, то возвращается уже созданный бин.

В эту переменную будет внедрена строка, например из property или из view.

Как обычно, просьба присылать правки или найденные ошибки в личку.

Источник

Руководство по Spring. Введение в Bean-ы.

Мы продолжаем наш цикл туториалов по Spring Framework, и сегодня речь пойдёт о сущности под названием Bean (бин).

Бины – это объекты, которые являются основой приложения и управляются Spring IoC контейнером. Эти объекты создаются с помощью конфигурационных метаданных, которые указываются в контейнере (например, XML- … ). Я уже говорил о них в предыдущих главах.

Определение бина содержит метаданные конфигурации, которые необходимы управляющему контейнеру для получения следующей информации:

В Spring Framework существуют такие свойства, определяющие бины:

class

Этот атрибут является обязательным и указывает конкретный класс Java-приложения, который будет использоваться для создания бина.

name

Уникальный идентификатор бина. В случае конфигурации с помощью xml-файла, вы можете использовать свойство “id” и/или “name” для идентификации бина.

scope

Это свойство определяет область видимости создаваемых объектов. (Прим. Отсутствие в русском языке достойного перевода этого свойства бинов могут вызвать затруднения, но более подробно оно будет рассмотрено далее).

constructor-arg

Определяет конструктор, использующийся для внедрения зависимости. Более подробно – далее.

properties

Определяет свойства внедрения зависимости. Более подробно рассмотрим далее.

initialization method

Здесь определяется метод инициализации бина

destruction method

Метод уничтожения бина, который будет использоваться при уничтожении контейнера, содержащего бин.

autowiring mode

Определяет режим автоматического связывания при внедрении зависимости. Более подробно рассмотрим далее.

lazy-initialization mode

Режим ленивой инициализации даёт контейнеру IoC команду создавать экземпляр бина при первом запросе, а не при запуске приложения.

Контейнер IoC не зависит от формата, в котором передаются метаданные. Существует 3 основных метода передачи метаданных контейнеру Spring IoC:

Ранее мы уже рассматривали как передаются метаданные на основе XML-файла. Теперь давайте рассмотрим пример XML-файла с различными свойствами

Конфигурирование бинов с помощью аннотаций мы рассмотрим позже в отдельной главе.

Источник

Урок 2: Введение в Spring IoC контейнер

Этот урок освещает работу с Spring Framework IoC контейнером и основан на оригинальной документации §5. The IoC container.

Что вы создадите

Вы создадите некоторое количество классов, в которых будет рассмотрена функциональность Spring Framework IoC контейнера.

Что вам потребуется

Настройка проекта

Введение

Inversion of Control (IoC), также известное как Dependency Injection (DI), является процессом, согласно которому объекты определяют свои зависимости, т.е. объекты, с которыми они работают, через аргументы конструктора/фабричного метода или свойства, которые были установлены или возвращены фабричным методом. Затем контейнер inject(далее «внедряет») эти зависимости при создании бина. Этот процесс принципиально противоположен, поэтому и назван Inversion of Control, т.к. бин сам контролирует реализацию и расположение своих зависимостей, используя прямое создание классов или такой механизм, как шаблон Service Locator.

Описание работы IoC контейнера

ApplicationContext представляет собой Spring IoC контейнер и необходим для инициализации, настройки и сборки бинов для построения приложения.

В метаданных конфигурации разработчик описывает как инициализировать, настроить IoC контейнер и собрать объекты в вашем приложении. В данном и других уроках этого цикла везде, где возможно, будет использоваться подход на основе аннотаций и Java-конфигурации. Если вы сторонник XML-конфигурации, либо хотите посмотреть как делать тоже самое через XML, обратитесь к оригинальной документации по Spring Framework или соответствующего модуля/проекта.

Настройка IoC контейнера

Как вариант, можно инициализировать контекст(ы) таким образом:

Использование @Bean аннотации

Теперь, для того, чтобы объект с типом GreetingService был доступен для использования, необходимо описать его в конфигурации следующим образом:

А для того, чтобы использовать его, достаточно выполнить следующее:

Метод getBean() может принимать в качестве аргумента как класс(как показано выше), так и названия бина(подробнее будет рассмотрено ниже), либо другие варианты, с которыми вы можете ознакомится в документации. Однако такой подход не рекомендуется использовать в production-конфигурациях, т.к. для подобных целей существует механизм Dependency Injection (DI), собственно говоря, для чего и предназначен Spring IoC контейнер. Использование DI будет рассмотрено ниже в отдельной главе.

Иногда полезно предоставить более подробное описание бина, например, в целях мониторинга. Для этого существует аннотация @Description :

Жизненный цикл бина

При совместном использовании методов, интерфейсов и аннотаций, описанных выше, учитывайте их порядок вызовов. Для методов инициализации порядок будет следующий:

Для методов разрушения порядок будет следующий:

Если вам необходимо реализовать свою собственную модель жизненного цикла бина, то в таком случае бин должен реализовывать один из интерфейсов, приведенных ниже:

После этого у вас появятся результаты работы методов при разрушении бина. Однако стоит заметить ещё раз, что это относится к обычным приложения, не относящимся к web-приложения(поскольку для них применяется отдельный тип контекста и подобный метод в них уже есть).

Области видимости(scopes) бинов

Когда вы создаете определение бинов, вы вы создаете рецепт для создания экземпляров класса, который определяет бин. Важно понять, что определение бинов является рецептом, потому что он означает, какого класса вы можете создать множество экземпляров по этому рецепту.

Использование @Configuration аннотации

Кода бин имеет зависимость от другого бина, то зависимость выражается просто как вызов метода:

В большинстве случаев, имеются такие случаи, когда бин в одной конфигурации имеет зависимость от бина в другой конфигурации. Поскольку конфигурация является источником определения бинов, то разрешить такую зависимость не является проблемой, достаточно объявить поле класса конфигурации с аннотацией @Autowired (более подробно оисано в отдельной главе):

При этом LessonsConfiguration остается без изменений:

Процесс разрешения зависимостей

IoC контейнер выполняет разрешение зависимостей бинов в следующем порядке:

Spring контейнер может разрешать зависимости между бинами через autowiring(далее, автоматическое связывание). Данный механизм основан на просмотре содержимого в ApplicationContext и имеет следующие преимущества:

Соответственно, у одной из реализации GreetingService должна быть установлена соответствующая аннотация @Qualifier :

Spring также поддерживает использование JSR-250 @Resource аннотации автоматического связывания для полей класса или параметров setter-методов:

Использование стандартных JSR-330 аннотаций

Spring Framework поддерживает JSR-330 аннотации. Эти аннотации работают таким же способом, как и Spring аннотации. Для того, чтобы работать с ними, необходимо добавить в pom.xml следующую зависимость:

Ниже приведена таблица сравнения JSR-330 и Spring аннотаций для DI:

Источник

Руководство по Spring. Жизненный цикл бинов.

Несмотря на кажущуюся сложность, жизненный цикл бинов крайне прост и лёгок для понимания. После создания экземпляра бина, могут понадобиться некоторые действия для того, чтобы сделать его работоспособным. Также при удалении бина из контейнера, необходима очистка.

В документации указан список того, что происходит с бином от момента создания до момента уничтожения. Но для начального понимания нам необходимо разобраться в двух наиболее важных методах, которые вызываются во время инициализации бина и его уничтожения.

Для управления созданием и уничтожением бина у нас есть параметры init-method и destroy-method.

Вызов функции инициализации

Интерфейс pro.springframework.beans.dactory. InitializingBean имеет только один метод – void afterPropertiesSet() throws Exception

А вот пример класса, который имплементирует InitializingBean:

Если мы конфигурируем бин с помощью XML-файла, то мы можем использовать атрибут init-method, чтобы определить, что именно будет происходить при создании экземпляра бина:

Конфигурационный файл configure-message-bean.xml

Вызов функции деструкции (уничтожения)

Интерфейс org.springframework.beans.factory.DsiposableBean также имеет только один единственный метод

void destroy() throws Exception.

Если же мы конфигурируем бин с помощью xml-файла, то мы должны использовать атрибут destroy-method для того, чтобы определить, что именно будет происходить при уничтожении экземпляра бина.

Конфигурационный файл configure-message-bean.xml

В общем случае не рекомендуется использовать InitializingBean и DisposableBean, так как конфигурирование с помощью XML-файла более удобно благодаря возможности иметь собственные методы.

Пример небольшого приложения:

Исходный код проекта можно скачать по ЭТОЙ ССЫЛКЕ.

Конфигурационный файл message-bean.xml

Результат работы программы

Если у Вас есть много бинов, и по одному методу инициализации и уничтожения, которые вы хотите использовать ко всем экземплярам бинов, Вы может не прописать их для каждого бина отдельно, а объявить их следующим способом:

В этот раз мы изучили основы жизненного цикла бинов. Другие аспекты жизненного цикла мы рассмотрим в последующих статьях.

Источник

Русские Блоги

Жизненный цикл Spring Bean

Обзор

Жизненный цикл компонента ApplicationContext

Обработать

В контейнере ApplicationContext процесс жизненного цикла Bean показан на рисунке выше, и процесс выглядит примерно следующим образом:

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

2. В соответствии с информацией о конфигурации информации об определении компонента, введите все атрибуты,

3. Если объект Bean реализует интерфейс BeanNameAware, он обратится к методу setBeanName () интерфейса и передаст идентификатор объекта Bean. В это время объект Bean получит свой идентификатор в файле конфигурации.

4. Если Bean реализует интерфейс BeanFactoryAware, он обратится к методу setBeanFactory () интерфейса и передаст BeanFactory Bean, так что Bean получит свою собственную BeanFactory.

5. Если Bean реализует интерфейс ApplicationContextAware, он обратится к методу setApplicationContext () интерфейса и передаст ApplicationContext Bean, так что Bean получит свой собственный ApplicationContext.

6. Если Bean реализует интерфейс BeanPostProcessor, он обратится к методу postProcessBeforeInitialization () интерфейса,

7. Если Bean реализует интерфейс InitializingBean, он обратится к методу afterPropertiesSet () интерфейса,

8. Если компонент настроен с помощью метода init-method, будет выполнен метод настройки метода init.

9. Если Бин реализует интерфейс BeanPostProcessor, он обратится к методу postProcessAfterInitialization () интерфейса,

10. После процесса 9 вы можете официально использовать bean-компонент. Для bean-компонента, имеющего одноэлементную область видимости, экземпляр bean-компонента будет кэшироваться в контейнере ioc Spring, а для bean-компонента, область действия которого является prototype, он будет новым каждый раз при вызове. Для нового объекта жизненный цикл передается вызывающей стороне для управления и больше не управляется контейнером Spring.

11. После закрытия контейнера, если Bean реализует интерфейс DisposableBean, он вызовет метод destroy () интерфейса.

12. Если Бин настроен с помощью метода destroy-method, будет выполнен метод конфигурации метода уничтожения. На этом этапе весь жизненный цикл Бина заканчивается.

пример

Когда мы запускаем контейнер, мы видим весь процесс вызова:

BeanFactory Жизненный цикл компонента

Обработать

В контейнере BeanFactoty жизненный цикл компонента показан на рисунке выше. По сравнению с ApplicationContext есть следующие отличия:

1. В контейнере BeanFactory метод setApplicationContext () интерфейса ApplicationContextAware не вызывается.

2. Методы postProcessBeforeInitialization () и postProcessAfterInitialization () интерфейса BeanPostProcessor не будут вызываться автоматически, вы должны вручную зарегистрироваться через код

3. Когда контейнер BeanFactory запущен, он не будет создавать экземпляры всех Bean-компонентов, включая все bean-компоненты, чья область видимости является singleton и не загружаются лениво, но будут созданы при вызове.

пример

Мы по-прежнему используем ранее определенные классы Person и MyBeanPostProcessor, а также файл ApplicationContext.xml. Основная функция реализована следующим образом:

Запускаем контейнер, видим весь поток вызовов:

Источник