싱글톤 컨테이너(4) - @Configuration과 바이트코드

@Configuration과 바이트코드

스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 전 게시물은 자바 코드를 3번 호출 하는 것이 맞다. 그래서 스프링은 클래스의 바이트 코드를 조작하는 라이브러리를 사용한다.
@Configuration을 적용한 AppConfig 클래스 타입을 보면 $$SpringCGLIB$$0이 붙는다.

순수한 클래스라면 example.core.AppConfig가 출력되어야한다.

AppConfig$$SpringCGLIB$$0
내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig클래스를 상속받은 임의의 다른 클래스를 만들고 , 그 다른 클래스를 스프링 빈으로 등록한 것이다.

AppConfig$$SpringCGLIB$$0가 싱글톤을 보장해준다.

AppConfig$$SpringCGLIB$$0예상코드(실제로는 CGLIB 내부 기술을 사용하는데 매우 복잡함)

@Bean
public MemberRepository memberRepository(){
	
    if(memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면){
    	return 스프링 컨테이너 찾아서 반환;
    }else { // 스프링 컨테이너 없으면
    	기존 로직 호출해서 	MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
		return 반환
	}
}

@Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고 , 스프링 빈이 없으면 생성하여 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다. 따라서 싱글톤이 보장되는 것이다.

참고 :AppConfig$$SpringCGLIB$$0는 AppConfig의 자식 타입으로 AppConfig 타입으로 조회할 수 있다.

만약 @Configuration을 주석처리 한다면 ?

CGLIB 기술없이 순수한 AppConfig가 스프링 빈에 등록된 것을 알 수 있다.

해당 출력결과를 통해 MemberRepository가 총 3번 출력된 것을 알 수 있다. 첫번째는 @Bean에 의해 스프링 컨테이너에 등록하기 위해서고 나머지 두번은 memberRepository()를 호출하면서 발생한 코드다.

인스턴스가 같은지 테스트 결과

각각 다른 참조값의 MemoryMeberRepository를 갖기 때문에 실패한다.

정리
- @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.
     ㄴ memberRepository()처럼 의존관계 주입이 필요해서 메서드를 호출할 떄 싱글톤을 보장하지 않는다.
- 스프링 설정 정보는 항상 @Configuration을 사용하자