@Configuration과 싱글톤

@Configuration과 싱글톤

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

AppConfig 코드에서 빈을 만들 때, memberService에서 memberRepository()를 호출하며 orderService에서도 memberRepository()를 호출한다.

• memberRepository()는 new MemoryMemberRepository()를 반환하므로 결과적으로 각각 다른 2개의 객체가 생성함을 예측할 수 있다.

테스트 코드로 검증을 해보겠다.

public class ConfigurationTest {

    @Test
    void configurationTest(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberServiceImpl memberService = ac.getBean("memberService",MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService",OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);
        
        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();
        MemberRepository memberRepository3 = memberRepository;

        System.out.println("memberRepository1 = " + memberRepository1);
        System.out.println("memberRepository2 = " + memberRepository2);
        System.out.println("memberRepository3 = " + memberRepository3);
    }
}

처음에 예상한 각각 다른 2개의 인스턴스가 생성될 줄 알았으나, 결과에서 보듯이 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용된다.

AppConfig에 출력문을 추가하여 호출 로그를 통해 예제를 살펴보겠다.

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService(){
        System.out.println("call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }

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

    @Bean
    public OrderService orderService(){
        System.out.println("call AppConfig.orderService");
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    private static DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }

}

예측 결과
call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository

우리의 예상대로라면 memberRepository가 3번 호출되어야 한다.
하지만 결과는 한 번 호출되었다.

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

스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 할 수는 없다. 위의 자바 코드에서 memberRepository는 3번 호출되어야 하지만 1번 호출되었다.
모든 비밀은 @Configuration을 적용한 AppConfig에 있다.

@Test
void configurationDeep() {

    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    
    //AppConfig도 스프링 빈으로 등록된다.
    AppConfig bean = ac.getBean(AppConfig.class);
    
    System.out.println("bean = " + bean.getClass());
    // 출력: bean = class hello.core.AppConfig$$EnhancedBySpringCGLIB$$bd479d70
}

• AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다. 그래서 AppConfig 도 스프링 빈이 된다
• AppConfig 스프링 빈을 조회해서 클래스 정보를 출력해보자

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

순수한 클래스라면 다음과 같이 출력되어야 한다.
class hello.core.AppConfig

그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다. 그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다.

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

@Configuration을 주석처리 한 후 테스트를 해보았다.

싱글톤이 유지되지 않고 여러 객체가 생성되는 것을 볼 수 있다.

@Configuration을 무조건 붙여 사용하자. 싱글톤 보장되고 편하다.

출처
김영한 스프링 핵심 원리 - 기본편