[스프링 핵심 원리 - 기본편] 인프런 강의 정리(싱글톤 컨테이너 - @Configration과 싱글톤)

/* 이 글은 김영한님의 강의를 보고 정리하려고 작성한 글입니다.

   개인적인 공부를 위해 올리는 글이므로 중간 중간 코드는 생략되었습니다. */

 

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

 

 

 

 

 

@Configration과 싱글톤

 

 

AppConfig

 

@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();
    }

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

}

 

✔ @Bean memberService ➔ new MemoryMemberRepository() 

✔ @Bean orderService ➔ new MemoryMemberRepository(), new RateDiscountPolicy()

✔ 위 코드를 보면 각각 다른 2개의  MemoryMemberRepository가 생성되면서 싱글톤이 깨지는 것 처럼 보인다.

 ➔ 스프링 컨테이너는 이 문제를 어떻게 해결할까?

 

 

 

 

MemberServiceImpl, OrderServiceImpl

 

//테스트 용 코드 추가
public MemberRepository getMemberRepository() {
    return memberRepository;
}

 

✔ MemberServiceImpl, OrderServiceImpl에 각각 테스트 코드 추가

 

 

 

 

ConfigurationSingletonTest

 

public class ConfigurationSingletonTest {

    @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);

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

    }

}

✔ 콘솔창을 확인해보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용된다.

✔ AppConfig의 자바 코드를 보면 `new MemoryMemberRepository` 호출해서 다른 인스턴스가 생성되어야 하는데 어떻게 된 일일까?

 

 

 

 

AppConfig

 

@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() {
        System.out.println("Call AppConfig.discountPolicy");
        return new RateDiscountPolicy();
    }

}

 

✔ 로그를 남기고 테스트를 실행하면 각각 한 번만 호출하는 걸 볼 수 있다.

✔ 어떠한 방법을 써서라도 스프링이 싱글톤을 보장해주는 걸 알 수 있음. 어떠한 방법인진 다음 강의에!

 

 

💡 TIP

:  sout 종류

 

◾ sout : `System.out.printil()` 생성

◾ soutv : 변수 출력

void configurationTest() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
    System.out.println("memberService = " + memberService);
}

◾ soutp : 매개변수 값 출력

public void join(Member member) {
    memberRepository.save(member);
    System.out.println("member = " + member);
}

◾ soutm : 현재 클래스의 메서드 출력

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

 

 

 

 

 

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

 

 

ConfigurationSingletonTest

 

@Test
void configurationDeep() {

    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 클래스를 상속받은 임의의 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록했다.

 

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

@Bean
public MemberRepository memberRepository() {

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

}

 

✔ 실제로 CGLIB 내부 기술은 굉장히 복잡하나, 간단히 적으면 위처럼 되어있을 것이라고 함.

✔ @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 스프링 빈으로 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.

 

 

 

만약 @Configuration을 붙이지 않고 @Bean만 적용한다면?

 

◾ AppConfig에서 @Configuration을 지우고 configurationDeep() 테스트

 

✔ MemberRepository는 총 3번 호출됐다. 

 - 1. @Bean에 의해 스프링 컨테이너에 등록되기 위해

 - 2. memberService에서 memberRepository()를 호출해서

 - 3. orderService에서 memberRepository()를 호출해서

✔ AppConfig가 CGLIB 기술없이 순수한 AppConfig로 스프링 빈에 등록됐다.

 

 

◾ AppConfig에서 @Configuration을 지우고 configurationTest () 테스트

 

✔ memberRepository의 인스턴스 값이 다른것을 알 수 있고 테스트에 실패한다.

✔ 싱글톤이 보장되지 않음.

 

 

 

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

고민할 것 없이 스프링 설정 정보는 항상 @Configuration을 사용하자!