195일차(모험 104일차) - @Configuration과 바이트코드 조작의 마법

[add] @Configuration과 바이트코드 조작의 마법 [#21] #27

스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다.

그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다.

이 전에 자바 코드를 보면 분명 3번 호출되어야 하는 것이 맞다.   @Configuration과 싱글톤                        

그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

모든 비밀은 @Configuration 을 적용한 AppConfig 에 있다

 

 

 

 

 

ConfigurationSingletonTest에 코드를 작성한 후 실행했다.

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 스프링 빈으로 등록된다.

그래서 AppConfig 도 스프링 빈이 된다.

 

AppConfig 스프링 빈을 조회해서 클래스 정보를 출력해보면 아래와 같이 나온다.

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$9d8eeb42

 

 

 

순수한 클래스라면 아래와 같이 출력되어야 한다.

class hello.core.AppConfig

 

 

그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다.

이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서

AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고,

그 다른 클래스를 스프링 빈으로 등록한 것이다.

 

 

AppConfig가 있다.

CGLIB라는 바이트코드 조작 라이브러리를 가지고 상속받아서 다른 클래스를 만든다.

스프링이 AppConfig@CGLIB라는 조작한 클래스를 스프링 빈으로 등록한다.

 

그래서 스프링 컨테이너에는 이름은 AppConfig인데 

instance 객체가 AppConfig@CGLIB 인 것이다.

 

바로 그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다.

 

 

 

 

 

아마도 다음과 같이 바이트 코드를 조작해서 작성되어 있을 것이다.

 

AppConfig@CGLIB 예상 코드

AppConfig를 호출하는 것 같지만 실제로는 AppConfig@CGLIB이고

memberRepository가 오버라이드 된 메소드가 실행되는 것이다. 

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

처음에 호출이 되면 스프링 컨테이너에 등록이 되어있지 않기 때문에 else를 타서

기존 로직을 호출한다.

 

⬇️ 기존 로직

@Bean
public MemberRepository memberRepository() {
    System.out.println("call AppConfig.memberRepository");
    return new MemoryMemberRepository();
}

MemoryMemberRepository를 스프링 컨테이너에 등록을 할 것이다. 

 

그런데 2번째부터 memberRepository를 호출하게 되면

memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으므로 

스프링 컨테이너에서 찾아서 있는 것을 반환한다.

 

 

 

 

@Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고,

스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.

덕분에 싱글톤이 보장되는 것이다.

 

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

 

 

 

 

 

 

 

@Configuration 을 적용하지 않고, @Bean 만 적용하면 어떻게 될까?

@Configuration 을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만,

만약 @Bean만 적용하면 어떻게 될까?

 

//@Configuration 삭제
public class AppConfig {
}

 

AppConfig에서 @Configuration 를 없애고

이 전과 동일하게 ConfigurationSingletonTest 를 실행해봤다.

 

자세한 내용은 pdf를 참고하고 넘어간다.

 

 

 

 

정리

@Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.

memberRepository() 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때

싱글톤을 보장하지 않는다.

 

 

💡 스프링 설정 정보는 항상 @Configuration 을 사용한다.