@Configuration과 바이트코드 조작의 마법

• @Bean만 사용해도 스프링 빈으로 등록되지만 싱글톤 보장하지 않는다. memberRepository()처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다!!! => 스프링 설정 정보는 항상 @Configuration을 사용하도록 한다!

"스프링이 빈을 등록할 때 조작이 일어난다."

사실 AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 스프링 빈으로 등록된다. 그래서 AppConfig 도 스프링 빈이 된다.

순수한 클래스라면 class hello.core.AppConfig 처럼 출력되어야 한다. 하지만 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스 를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다!

참고 AppConfig@CGLIB는 AppConfig의 자식 타입이므로, AppConfig 타입으로 조회 할 수 있다.

아마도 다음과 같이 바이트 코드를 조작해서 작 성되어 있을 것이다.(실제로는 CGLIB의 내부 기술을 사용하는데 매우 복잡하다.)

AppConfig@CGLIB 예상 코드 : 같은 메서드를 여러번 호출해도 하나의 인스턴스만 존재하는 이유. @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다. =>덕분에 싱글톤이 보장되는 것이다!

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

하지만 이러한 @Configuration이 없다면 어떻게 될까?

똑같이 스프링 빈에 등록되기는 하지마나 AppConfig의 모든 클래스들은 순수한 자바 코드이다. 스프링 컨테이너가 관리하지 않는다. 그렇기 때문에 같은 테스트코드를 돌려보면 memberRepository가 총 3번 호출되고, 인스턴스들 또한 다 다른 것임을 알 수 있다.