Springboot 자동 조립 원리

간단히 말해서 Springboot 자동 조립은 Bean을 Ioc 컨테이너에 자동으로 조립하는 것인데, Springboot 자동 조립을 이해하기 전에 Spring이 Bean을 주입하고 구성하는 방법에 대해 알아보겠습니다.

스프링 Ioc/DI

loC(Inversion of Control) 및 DI(Dependency Injection)의 전체 이름은 각각 Inversion of Control 및 Dependency Injection입니다. 이 두 개념을 이해하는 방법은 무엇입니까?

loC

loC(Inversion of Control)는 실제로 Spring컨테이너에서 객체의 생명주기를 주관하며, 역전은 객체획득방식이 거꾸로 된 것을 의미한다. 아래 그림은 객체를 생성하는 전통적인 방법을 보여줍니다.클라이언트 클래스가 User 및 UserDetail을 사용해야 하는 경우 new를 통해 빌드해야 합니다.이렇게 하면 코드 간의 결합이 매우 높아집니다.

이미지-20220502090416402

Spring loC 컨테이너를 사용한 후 클라이언트 클래스는 new를 통해 이러한 객체를 생성할 필요가 없습니다.그림 2는 그림 1을 기반으로 loC 컨테이너를 추가합니다. 빌드를 생성하지만 loC 컨테이너에서 직접 생성합니다. 그렇다면 Spring loC 컨테이너의 객체는 언제 빌드되었는가?초기 Spring에서 bean은 주로 XML을 통해 정의되었으며 Spring은 XML 파일을 구문 분석하고 정의된 bean을 loC 컨테이너에 로드합니다.

그림 2

에서

DI(Dependency Inject), 즉 종속성 주입은 단순히 loC 컨테이너가 런타임 중에 특정 종속성을 구성 요소에 동적으로 주입한다는 것을 이해했습니다. DI의 개념을 완전히 이해하기 위해 계속해서 위의 그림 2를 살펴보겠습니다. Spring 구성 파일에는 User와 UserDetail이라는 두 개의 bean이 설명되어 있는데, 이 두 객체는 구성 파일과는 관계가 없지만 실제로 클래스의 관계 다이어그램에서는 두 개체 사이에 aggregation 관계가 있습니다. 이 집계 관계가 loC 컨테이너에 자동으로 삽입되도록 하려면, 즉 이 코드와 같이 user.getUserDetail을 통해 UserDetail 인스턴스를 가져오려면 어떻게 해야 합니까?

ApplicationContext context = new FileSystemXmlApplicationContext("...");
User user = context.getBean(User.class);
UserDetail userdetail = user.getUserDetail();

사실 Spring 설정파일에 bean사이의 의존성만 기술하면 되는데 Ioc컨테이너가 설정파일을 파싱하면 bean의 의존성에 따라 주입하게 되는데 이 과정이 의존성 주입이다.

<bean id="user" class="User">
	<property name="userDetail" ref="userDetail"/>
</bean>
<bean id="userDetail" class="UserDetail"/>

종속성 주입을 구현하는 세 가지 방법, 즉 인터페이스 주입, 생성자 주입 및 setter 메서드 주입이 있습니다. 그러나 이제는 기본적으로 @Autowired, @Inject 및 @Resource와 같은 bean 간의 종속성을 설명하는 주석을 기반으로 합니다.

Bean 조립 방식 업그레이드

XML 기반의 구성 방식은 객체 선언 주기의 기술 및 관리를 잘 완료하지만, 프로젝트 규모가 계속 확장됨에 따라 XML 구성이 점차 증가하여 구성 파일을 관리하기 어렵습니다. 반면에 프로젝트의 종속성은 점점 더 복잡해지고 구성 파일을 이해하기 어려워집니다. 이러한 문제를 해결할 수 있는 방안이 시급한 실정이다.
Spring 2.x부터 JDK 1.5에서 가져온 주석 지원으로 주석을 사용하여 빈을 선언하고 주입할 수 있으므로 XML 구성의 양이 크게 줄어듭니다.
Spring이 3.x로 업그레이드된 후 XML을 완전히 대체할 수 있는 JavaConfig 기능을 제공하고 Java 코드를 통해 Bean 주입을 완료합니다. 따라서 현재 우리가 사용하는 Spring Framework나 Spring Boot에는 XML 구성의 존재가 보이지 않습니다.

XML 구성 방법

<?xm1 version="1.0" encoding="UTF-8"?>
<beans xmIns="http:/ /www . springframework.org/schema/beans"
	   xmIns:xsi="http: / / www. w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
<! --bean的描述-->
</beans>

javaConfig 형식을 사용한 후에는 XML 구성 형식과 동일한 @Configuration 주석만 사용하면 됩니다.

@Configuration
public class Springconfigclass{
    
    
// Bean 的描述
}

빈이 로드되는 방식의 변경 사항

XML 기반 로딩 방식

<bean id="beanDefine" class="com.gupaoedu.spring.BeanDefine"/>

JavaConfig의 설정 형태를 기반으로 @Bean 어노테이션을 통해 객체를 loC 컨테이너에 주입할 수 있으며, 기본적으로 메소드 이름이 빈의 id로 사용된다.

@Configuration
public class SpringConfigclass{
    
    
    @Bean
	public BeanDefine beanDefine(){
    
    
    	return new BeanDefine();
    }
}

종속성 주입 변경

XML 형식에서 종속성 주입은 세터 주입과 같은 세 가지 방법으로 수행할 수 있습니다.

<bean id="beanDefine" class="com.scmpe.spring.BeanDefine">
	<property name="dependencyBean" ref="dependencyBean"/>
</bean>
<bean id="dependencyBean" class="com.scmpe.spring.dependencyBean"/>

JavaConfig에서는 다음과 같이 표현할 수 있습니다.

public class SpringConfigClass{
    
    
    @Bean
    public BeanDefine beanDefine() {
    
    
        public BeanDefine=new BeanDefine();
        beanDefine.setDependencyBean(dependencyBean());
        return beanDefine;
    }
	@Bean
    public DependencyBean dependencyBean() {
    
    
        return new DependencyBean();
    }
}

기타 구성 변경

이전 구성 외에도 다음과 같은 일반적인 구성이 있습니다.

@ComponentScan은 XML 형식의 <context:component-scan base-package="">에 해당하며 지정된 패키지 경로 아래에 @Service, @Repository, @Controller, @Component 등으로 주석이 달린 클래스를 스캔하고 로드합니다. 이러한 클래스를 IoC 컨테이너에 넣습니다.
@Import는 XML 형식에 해당하며 다른 구성 파일을 가져옵니다.
어노테이션을 통해 빈을 어셈블하면 XML 구성으로 인한 문제를 어느 정도 줄일 수 있지만 다음과 같은 본질적인 문제는 여전히 해결되지 않습니다.
너무 많은 의존. Spring은 JSON, MyBatis, Redis, Log 등과 같이 일반적으로 사용되는 거의 모든 기술 프레임워크를 통합할 수 있습니다. 서로 다른 종속 패키지의 버전은 버전 호환성 문제로 쉽게 이어질 수 있습니다.
구성이 너무 많습니다. JavaConfig를 사용하여 MyBatis를 통합하기 위해 Spring을 예로 들면 주석 드라이버 구성, 데이터 소스 구성, MyBatis 구성, 트랜잭션 관리자 구성 등이 필요합니다. 유사한 반복 작업을 많이 해야 합니다.
실행 및 배포가 번거롭습니다. 프로젝트를 먼저 패키징한 다음 컨테이너에 배포해야 합니다.

개발자가 더 이상 이러한 문제에 주의를 기울이지 않고 비즈니스에 집중할 수 있도록 하는 방법 다행히도 Spring Boot가 탄생했습니다.

스프링부트

Spring Boot는 새로운 기술 프레임워크가 아닙니다. 주요 기능은 Spring 응용 프로그램의 개발을 단순화하는 것입니다. 개발자는 소량의 코드만 사용하여 프로덕션 수준의 Spring 응용 프로그램을 만들면 됩니다. 이 목표를 달성하기 위한 핵심 아이디어는 "계약"입니다. 구성보다 낫다(구성보다 관례)".

Spring Boot에서 구성보다 컨벤션의 아이디어는 주로 다음과 같은 측면에 반영됩니다(포함하되 이에 국한되지 않음).

Maven 디렉토리 구조에 대한 규약.
Spring Boot의 기본 구성 파일 및 구성 파일의 구성 속성 규칙.
Spring MVC 종속성의 경우 내장 Tomcat 컨테이너에 자동으로 종속됩니다.
스타터 구성 요소에 대한 배선은 자동으로 수행됩니다.

스프링 부트의 핵심

Spring Boot는 Spring Framework 시스템을 기반으로 구축되었기 때문에 새로울 것은 없지만 Spring Boot를 잘 배우려면 핵심을 알아야 합니다.

스타터 구성 요소는 즉시 사용 가능한 구성 요소를 제공합니다.
자동 조립은 컨텍스트에 따라 콩의 조립을 자동으로 완료합니다.
Actuator, Spring Boot 애플리케이션 모니터링.
Spring Boot CLI는 명령줄 도구를 기반으로 Spring Boot 애플리케이션을 신속하게 빌드합니다.

그 중 핵심부품은 자동조립이어야 하며, Starter 컴포넌트의 핵심부품 역시 자동조립을 기반으로 구현된다.

SpringBoot 자동 조립 원리

Springboot 자동 조립에 대한 간략한 개요는 빈을 Ioc 컨테이너에 자동으로 조립하는 것입니다.다음으로 Redis를 통합하는 Spring boot의 예제를 통해 자동 조립에 대해 알아보겠습니다.

스테이터 종속성 추가

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

application.properties에서 Redis의 데이터 소스를 구성합니다.

spring.redis.host=localhost
spring.redis.port=6379

TestController에서 RedisTemplate을 사용하여 Redis 작업 구현

@Restcontroller
public class HelloController {
    
    
	@Autowired
	RedisTemplate<String, string> redisTemplate;
    @GetMapping( "/hello")
    public String hello(){
    
    
    	redisTemplate.opsForValue().set("key" , "value");return "He1lo world";
    }
}

이 예제에서는 RedisTemplate을 Ioc 컨테이너에 주입하지 않았지만 HelloController는 @Autowired를 직접 사용하여 redisTemplate 인스턴스를 주입할 수 있습니다. 이는 Ioc 컨테이너에 이미 RedisTemplate이 있음을 의미합니다. 이것은 스프링 부트의 자동 어셈블리입니다.스타터 종속성을 추가하기만 하면 종속 구성 요소와 관련된 빈의 자동 주입이 완료됩니다.이 메커니즘의 구현은 일종의 합의를 기반으로 해야 한다고 추측하는 것은 어렵지 않습니다. Springboot 자동 조립을 준수하려면 Starter 구성 요소만 있으면 자동 조립 계약의 사양을 지정하여 실현할 수 있습니다.

자동조립 구현

시작 클래스 주석 @SpringbootApplication에 선언된 @EnableAutoConfiguration 주석을 통해 Springboot에서 자동 어셈블리가 활성화됩니다.

@SpringBootApplication
public class SpringBootDemoApplication {
    
    
	public static void main(String[] args){
    
    
		SpringApplication.run(SpringBootDemoApplication.class, args);
    }
}

@EnableAutoConfiguration 주석을 보려면 @SpringBootApplication을 입력하십시오.

@Target(ElementType. TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = {
    
    @Filter(type = FilterType.CUSTOM,classes =TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public interface SpringBootApplication {
    
    
...
}

여기에서 먼저 @Enable 주석을 소개합니다. Spring 3.1 버전은 @Enable 주석을 지원하기 시작했으며 주요 기능은 관련 구성 요소의 빈을 Ioc 컨테이너로 어셈블하는 것입니다. @Enable 어노테이션은 JavaConfig를 더욱 향상시켜 Spring Framework를 사용하는 개발자의 설정량과 사용의 어려움을 줄여줍니다. 예를 들어 일반적인 @Enable 주석에는 @EnableWebMvc, @EnableSheduling 등이 포함됩니다.

앞서 javaConfig 형태로 Bean 로딩을 완료했다면 @Configuration 어노테이션과 @Bean 어노테이션을 사용해야 한다고 말씀드렸습니다. 그리고 @Enable은 본질적으로 이 두 주석의 캡슐화입니다. 이러한 주석에 주의를 기울이면 @EnableScheduling과 같은 @Import 주석이 모두 포함되어 있음을 알 수 있습니다.

@Target({
    
    ElementType. TYPE})
@Retention(RetentionPolicy. RUNTIME)
@Import({
    
    SchedulingConfiguration.class})Documented
public @interface EnableScheduling {
    
    }

@Enable 주석을 사용한 후 Spring은 @Import에 의해 가져온 구성 클래스를 구문 분석하여 이 구성 클래스의 설명에 따라 Bean 어셈블리를 실현합니다. 그렇다면 @EnableAutoConfiguration의 구현 원리가 같은 것인지 생각해 볼 수 있습니다.

자동 구성 활성화

@EnableAutoConfiguration 주석을 입력하면 @Import 주석 외에도 추가 @AutoConfigurationPackage 주석이 있음을 알 수 있습니다(이 주석의 기능은 주석을 사용하는 클래스의 패키지 및 하위 패키지 아래의 모든 구성 요소를 스캔하여 컨테이너의 Spring Ioc).

또한 @Import 어노테이션에서 가져온 것은 Configuration 구성 클래스가 아니라 AutoConfigurationImportSelector 클래스입니다.

@Target(ElementType. TYPE)
@Retention( RetentionPolicy.RUNTIME)@Documented
@Inherited
@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)public @interface EnableAutoConfiguration

그러나 AutoConfigurationImportSelector가 무엇이든 반드시 구성 클래스 가져오기를 구현할 것이므로 구체적인 구현 방법에 대해서는 계속 분석해야 합니다.

자동 구성 가져오기 선택기

AutoConfigurationImportSelector는 ImportSelector를 구현합니다. 하나의 selectorImports 추상 메서드만 가지며 String 배열을 반환합니다. 이 배열에서 Ioc 컨테이너로 어셈블해야 하는 클래스를 지정할 수 있습니다. ImportSelector 구현 클래스를 @Import로 가져올 때 구현 클래스는 반환된 클래스 이름은 모두 Ioc 컨테이너에 로드됩니다.

public interface ImportSelector {
    
    
    String[] selectImports(AnnotationMetadata var1);
}

@Configuration과 달리 ImportSelector는 배치 어셈블리를 구현할 수 있으며 논리적 처리를 통해 Bean의 선택적 어셈블리도 구현할 수 있습니다. 즉, Ioc 컨테이너에 의해 초기화될 컨텍스트에 의해 결정될 수 있습니다. 다음으로 ImportSelector의 사용을 이해하기 위한 간단한 예를 살펴보겠습니다.

먼저 두 개의 클래스를 만들고 이 두 클래스를 Ioc 컨테이너로 어셈블해야 합니다.

public class Firstclass {
    
    
    
}
public class Secondclass {
    
    
    
}

ImportSelector의 구현 클래스를 만들고 정의된 두 개의 빈을 구현 클래스의 문자열 배열에 추가합니다. 이는 이 두 개의 빈이 Ioc 컨테이너로 어셈블됨을 의미합니다.

public class GpImportSelector implements ImportSelector {
    
    
	@Override
	public String[] selectImports(AnnotationMetadata importingClassMetadata) {
    
    
		return new String[]{
    
    FirstClass.class.getName() ,SecondClass.class.getName()};
    }
}

EnableAutoConfiguration을 시뮬레이션하기 위해 유사한 주석을 사용자 지정하고 @Import를 통해 GpImportSelecto를 가져올 수 있습니다.

@Target(ElementType. TYPE)
@Retention(RetentionPolicy. RUNTIME)@Documented
@Inherited
@AutoConfigurationPackage
@Import(GpImportSelector.class)
public @interface EnableAutoImport {
    
    
}

시작 클래스를 만들고 시작 클래스에서 @EnableAutoImport 주석을 사용하여 ca.getBean을 통해 Ioc 컨테이너에서 First 개체 인스턴스를 가져옵니다.

@SpringBootApplication@EnableAutoImport
public class ImportSelectorMain {
    
    
public static void main(String[ ] args){
    
    
	ConfigurableApplicationcontext ca=SpringApplication.run(ImportSelectorMain.class， args);
	FirstClass fc=ca.getBean(Firstclass.class);
}

@Import(*Configuration.class)와 비교하여 이 구현의 장점은 어셈블리의 유연성에 있으며 배치 어셈블리도 구현할 수 있습니다. 예를 들어 GpImportSelector는 String에 여러 Configuration 클래스를 직접 설정할 수도 있습니다.Configuration 클래스는 특정 기술 구성 요소의 Bean 선언 배치를 나타내므로 자동 프로세스에서 지정된 경로 아래에 해당 구성 클래스를 스캔하기만 하면 됩니다. 조립입니다.

자동 조립 원리 분석

앞서 분석한 내용을 바탕으로 자동 조립의 핵심은 합의된 디렉토리에 있는 파일을 스캔해 분석하는 것이라고 짐작할 수 있으며, 분석이 완료된 후 얻은 Configuration 구성 클래스를 ImportSelector를 통해 가져와 빈의 자동 조립을 완료한다. 그런 다음 AutoConfigurationImportSelector의 구현을 분석하여 이 추측을 증명합니다.

ImportSelector 인터페이스의 구현인 AutoConfigurationImportSelector에서 selectImport 메서드를 찾습니다. 이 방법에는 두 가지 주요 기능이 있습니다.

AutoConfigurationMetadataLoader.loadMetadata는 META-INF/spring-autoconfigure-metadata.properties에서 자동조립된 조건부 메타데이터를 불러오는데, 간단히 말해서 조건을 만족하는 빈만 조립할 수 있다.
자동 조립을 완료하기 위해 모든 규정된 구성 클래스 autoConfigurationEntry.getConfigurations()를 수집하십시오.

@Override
public String[ ] selectImports(AnnotationMetadata annotationMetadata){
    
    
    if ( !isEnabled(annotationMetadata)){
    
    
    return NO_IMPORTS;
    }
    AutoConfigurationMetadata autoConfigurationMetadata = 	AutoConfigurationMetadataLoader.loadMetadata(this.beanClassLoader);

    AutoConfigurationEntry autoconfigurationEntry =
    getAutoConfigurationEntry(autoConfigurationMetadata,annotationMetadata);

    return Stringutils.toStringArray(autoConfigurationEntry.getConfigurations());
}

여기에 문제가 있습니다 . 메소드의 로드 프로세스로 메소드를 SpringApplication.run(...)전송하는 방법은 아마도 다음과 같을 것입니다.selectImports()

SpringApplication.run(…) ->

AbstractApplicationContext.refresh() ->

invokeBeanFactoryPostProcessors(…) ->

PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(…) ->

ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(…) ->

AutoConfigurationImportSelector.selectImports

구성 클래스 수집 메서드인 getAutoConfigurationEntry의 분석에 초점을 맞추자 Starter의 이전 기능을 결합하면 이 메서드가 지정된 경로 아래의 파일을 스캔하고 분석하여 어셈블해야 하는 구성 클래스를 가져와야 한다고 추측하는 것은 어렵지 않습니다. , 그리고 여기에서는 SpringFactoriesLoader를 사용하는데 이 내용은 나중에 코드가 확장되면서 설명하겠습니다. 이 코드에 대한 간략한 분석은 주로 다음과 같은 몇 가지 작업을 수행합니다.

getAttributes @EnableAutoConfiguration 주석에서 exclude, excludeName 등의 속성을 가져옵니다.
getCandidateConfigurations 모든 자동 연결 구성 클래스를 가져옵니다.
removeDuplicates 중복 구성 항목을 제거합니다.
getExclusions는 @EnableAutoConfiguration 주석에 구성된 exclude 및 기타 속성에 따라 자동으로 어셈블할 필요가 없는 구성 클래스를 제거합니다.
fireAutoConfigurationImportEvents 브로드캐스트 이벤트.
마지막으로 다층 판단 및 필터링 후 구성 클래스 컬렉션을 반환합니다.

protected AutoConfigurationEntry getAutoConfigurationEntry(AutoConfigurationMetadataautoConfigurationMetadata,AnnotationMetadata annotationMetadata){
    
    
    if(!isEnabled(annotationMetadata)){
    
    
    	return EMPTY_ENTRY;
    }
    AnnotationAttributes attributes = getAttributes(annotationMetadata);
    List<String> configurations = getcandidateConfigurations(annotationMetadata, attributes);
    configurations = removeDuplicates(configurations);
    Set<String> exclusions = getExclusions( annotationMetadata,attributes);
    checkExcludedclasses( configurations,exclusions);
    configurations. removeAl1(exclusions);
    configurations = filter(configurations,autoConfigurationMetadata);
    fireAutoConfigurationImportEvents(configurations,exclusions);
    return new AutoConfigurationEntry(configurations,exclusions);
}

일반적으로 모든 구성 클래스를 먼저 가져오고 중복 제거 및 제외와 같은 작업을 통해 자동으로 어셈블해야 하는 최종 구성 클래스를 가져옵니다. 여기서 집중해야 할 것은 구성 클래스를 얻기 위한 핵심 메서드인 getCandidateConfigurations입니다.

protected list<String> getCandidateConfigurations(AnnotationMetadata metadata,AnnotationAttributes attributes) {
    
    
	List<String> configurations =
SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryclass(),getBeanclassLoader());
	Assert.notEmpty(configurations，"No auto configuration classes found inMETA-INF/spring.factories. If you " + "are using a custom packaging,make sure that file is correct.");
return configurations;
}

여기서는 SpringFactoriesLoader를 사용하는데, 이는 Java의 SPI와 유사한 Spring에서 제공하는 기존 로딩 방법입니다. 간단히 말해 classpath 아래 META-INF/spring.factories 파일을 스캔하고 spring.factories 파일의 데이터는 Key=Value 형식으로 저장되며 SpringFactoriesLoader.loadFactoryNames는 Key에 따라 해당 값을 가져옵니다. . 따라서 이 시나리오에서 Key는 EnableAutoConfiguration에 해당하고 Value는 여러 구성 클래스, 즉 getCandidateConfigurations 메서드에서 반환된 값입니다.

RabbitAutoConfiguration을 열면 JavaConfig를 기반으로 하는 구성 클래스임을 알 수 있습니다.

@Configuration(proxyBeanMethods = false)
@Conditional0nclass({
    
     RabbitTemplate.class,Channe1.class})
@EnableConfigurationProperties(RabbitProperties.class)
@Import(RabbitAnnotationDrivenConfiguration.class)
public class RabbitAutoConfiguration

기본적인 @Configuration 어노테이션 외에 @ConditionalOnClass 어노테이션도 존재하는데, 여기서 이 조건 제어 메커니즘의 목적은 클래스패스 아래에 RabbitTemplate과 Channel 두 개의 클래스가 있는지 판단하는 것이다. 그렇다면 현재 설정 클래스를 등록한다. IloC 컨테이너에. 또한 @EnableConfigurationProperties는 속성 구성이므로 application.properties에서 RabbitMQ 매개 변수를 규칙에 따라 구성할 수 있으며 이러한 구성은 RabbitProperties에 로드됩니다. 사실 이러한 것들은 모두 Spring 자체의 기능입니다.

구성 클래스 가져오기는 @Import(AutoConfigurationImportSelector)를 통해 구현되지만 이는 전통적인 의미에서 단일 구성 클래스 어셈블리가 아닙니다.
AutoConfigurationImportSelector 클래스는 ImportSelector 인터페이스를 구현하고 선택적 배치 구성 클래스의 어셈블리를 실현하는 데 사용되는 selectImports 메서드를 다시 작성합니다.
Spring에서 제공하는 SpringFactoriesLoader 메커니즘을 통해 classpath 경로 아래 META-INF/spring.factories를 스캔하고 자동으로 조립해야 하는 구성 클래스를 읽습니다.
조건부 심사를 통해 조건에 맞지 않는 구성 클래스를 제거하고 최종적으로 자동 조립을 완료합니다. 구성 클래스 가져오기는 @Import(AutoConfigurationImportSelector)를 통해 구현되지만 이는 전통적인 의미에서 단일 구성 클래스 어셈블리가 아닙니다.
AutoConfigurationImportSelector 클래스는 ImportSelector 인터페이스를 구현하고 선택적 배치 구성 클래스의 어셈블리를 실현하는 데 사용되는 selectImports 메서드를 다시 작성합니다.
Spring에서 제공하는 SpringFactoriesLoader 메커니즘을 통해 classpath 경로 아래 META-INF/spring.factories를 스캔하고 자동으로 조립해야 하는 구성 클래스를 읽습니다.
조건부 심사를 통해 조건에 맞지 않는 구성 클래스를 제거하고 최종적으로 자동 조립을 완료합니다.

Springboot 자동 조립 원리를 간단한 용어로 설명