[스프링 핵심 원리 - 기본편] @Configuration과 싱글톤

@Configuration과 싱글톤

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

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

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

    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

• memberService 빈을 만드는 코드를 보면 memberRepository() 를 호출한다.
  • 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

• orderService 빈을 만드는 코드도 동일하게 memberRepository() 를 호출한다.
  • 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

• 위의 코드만 보았을 때, 결과적으로 각각 다른 2개의 MemoryMemberRepository가 생성되면서 싱글톤이 깨지는 것처럼 보인다.

 

• 스프링 컨테이너 싱글톤 테스트

    @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();
        System.out.println("memberService -> memberRepository1 = " + memberRepository1);
        System.out.println("orderService -> memberRepository2 = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);

        assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);

    }

 

• memberRepository() 호출 예상
  • 1. 스프링 컨테이너가 스프링 빈에 등록하기 위해 @Bean이 붙어있는 memberRepository()호출
  • 2. memberService() 로직에서 의존관계 주입을 위해 memberRepository() 호출
  • 3. orderService() 로직에서 의존관계 주입을 위해 memberRepository() 호출

 

• 예상 결과 (memberRepository 3회 호출)
  • call AppConfig.memberService
  • call AppConfig.memberRepository
  • call AppConfig.orderService
  • call AppConfig.memberRepository
  • call AppConfig.memberRepository

 

• 실제 호출 결과는 다음과 같다.(memberRepository 1회 호출)
  • call AppConfig.memberService
  • call AppConfig.memberRepository
  • call AppConfig.orderService

 

• AppConfig의 자바 코드를 보면 분명히 각각 2번 new MemoryMemberRepository 호출해서 다른 인스턴스가 생성되어야하지만 실제로 확인해보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용된다.

 

@Configuration 사용 (바이트 코드 조작)

• 스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 위의 자바 코드를 보면 분명 new MemoryMemberRepository는 3번 호출되어야 하는 것이 맞다.

• 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다. 싱글톤을 유지하는 모든 비밀은 @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$$EnhancerBySpringCGLIB$$bd479d70
}

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

• AppConfig 스프링 빈을 조회해서 나온 클래스 정보(바이트코드가 조작된 클래스)
  • class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

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

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

  

• AppConfig@CGLIB 예상 코드

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

• @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.
  • 싱글톤이 보장된다.
  • 처음에는 memberRepository 객체가 컨테이너에 없어서 생성하지만 이후에는 생성된 객체를 사용하여 메모리 주소가 같다.

    

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

 

@Configuration 미사용

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

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

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

    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

• 바이트 코드가 조작된 클래스가 아니라 기존의 클래스 정보가 표시된다.

@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
}

• 또한 스프링에서 의존관계 주입 시 메서드를 직접 호출할 때, @Configuration 을 사용하면 바이트 코드를 조작하여 객체 인스턴스가 존재하면 재사용할 수 있도록(싱글톤)으로 처리해주지만 @Configuration 를 사용하지 않은 경우, 바이트 코드가 조작되지 않은 기존의 클래스 정보는 의존관계 객체를 재사용하는 부분이 없고 직접 의존관계 객체를 생성해서 주입해줌으로써 각각 다른 인스턴스가 생성된다.

  

 

• @Bean만 사용해도 스프링 빈으로 등록된다.
  • 스프링 빈에 등록될 때는 싱글톤으로 생성이 되지만 의존관계 주입을 위해 메서드를 직접 호출하는 경우, @Configuration 을 사용하지않았다면 의존관계 객체의 싱글톤은 보장하지 않는다. 그 이유는 바이트코드가 조작되지 않은 기존의 클래스에서는 의존관계에 있는 객체를 따로따로 생성해서 인자로 전달하기 때문이다.
  • 즉, memberRepository() 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.

---

[참고자료]

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