싱글톤 컨테이너 - @Configuration과 싱글톤

Configuration과 싱글톤

@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()를 호출하여 new MemoryMemberRepository()를 호출한다.
• 마찬가지로 orderService()에서도 결국 new MemoryMemberRepository()를 호출한다.
• 그러면 코드상으로만 봤을 때 각각 new MemoryMemberRepository()가 호출되어 싱글톤이 깨지는 것처럼 보인다

 

싱글톤 검증

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

System.out.println("memberService -> memberRepository = " + memberService.getMemberRepository());
System.out.println("orderService -> memberRepository = " + orderService.getMemberRepository());
System.out.println("memberRepository = " + memberRepository);

• 검증을 위해 MemberServiceImpl객체와 OrderServiceImpl에 memberRepository 객체를 반환하는 getMemberRepository() 메서드를 만들어 두고 테스트를 한다.
• 위에서 빈으로 등록한 세 개의 객체를 생성하여 같은 인스턴스를 사용하는지 검증한다.
• 앞에서 코드상으로 싱글톤이 깨지는 것처럼 보였지만, 실제로 출력을 해보면 모두 같은 인스턴스를 참조하고 있다.
• 코드상으론 memberRepository()가 3번 호출되어 각각 다른 객체가 생성될 것 처럼 보이지만
• 생성자에 출력문을 넣어봐도 생성자는 각각 한번씩만 호출된다.

 

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

• 스프링 컨테이너는 싱글톤 레지스트리로서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다.
• 하지만 스프링이 자바 코드까지 조작할 수는 없다.
• 그런데 자바 코드를 보면 분명 3번 호출되어야 하는 것이 맞다
• 어떻게 된 것 일까??

 

AppConfig 클래스 검증

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

AppConfig bean = ac.getBean(AppConfig.class);

System.out.println("bean = " + bean.getClass());

• AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다.
•  그래서 AppConfig도 스프링 빈이 되는데, 이 클래스 정보를 출력해보면

 

• 순수한 클래스라면 class hello.core.AppConfig의 형태로 출력되어야 한다.
• 하지만 ~~CGLIB가 붙으면서 아주 복잡한 정보가 출력된다.
• 이는 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용하여 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고
• 그 다른 클래스를 스프링 빈으로 등록한 것이다.

 

AppConfig@CGLIB 예상 코드

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

• 실제 코드는 더 복잡하지만 로직을 예상해보면
• 위의 코드 처럼 @Bean이 붙은 메서드 마다 이미 해당 스프링 빈이 존재하면 존재하는 빈을 반환하고,
• 스프링 빈이 없으면 새로 생성하여 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.
• 따라서 싱글톤이 보장된다.

 

@Configuration을 사용하지 않고, @Bean을 사용하면?

• 테스트 결과는 생략하지만, AppConfig 클래스 정보가 순수한 클래스인 class hello.core.AppConfig가 출력된다.
• 당연히 CGLIB 기술이 사용되지 않기 때문에, memberRepository()메서드가 3번 호출되며 
• 각각의 인스턴스가 다른 인스턴스를 참조하게 된다.

고민하지말고 스프링 설정 정보는 항상 @Configuration을 사용!!

 

 

 

 

 

---

출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

스프링 핵심 원리 - 기본편 - 인프런 | 강의