스프링 핵심원리 : 기본편 - @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/dashboard

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

@Configuration 과 싱글톤

@Configuration 어노테이션은 사실 싱글톤을 위해 존재한다.

AppConfig 를 한번 살펴보자.

 

- AppConfig.java

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 FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

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

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

결과적으로 각각 다른 2개의 MemoryMemberRepository 가 생성되면서 싱글톤이 깨지는 것 처럼 보인다.

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

 

직접 테스트 해보자.

MemberServiceImpl 과 OrderServiceImpl 클래스에 싱글톤 패턴 검증을 위해 다음과 같이 코드를 추가해보자.

- MemberServiceImpl.java -> getMemberRepository() 메소드 추가

public class MemberServiceImpl implements MemberService{

//    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository){
        this.memberRepository = memberRepository;
    }

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }

    // 테스트 용도
    public MemberRepository getMemberRepository(){
        return memberRepository;
    }
}

- OrderServiceImpl.java -> getMemberRepository() 메소드 추가

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    // final 키워드가 붙어있는 필드는 기본적으로 생성자를 통해 값을 할당해야 한다.
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);

        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }

    // 테스트 용도
    public MemberRepository getMemberRepository() {
        return memberRepository;
    }
}

 

테스트를 위해 두 클래스에 MemberRepository 를 조회할 수 있는 기능을 추가한다. 기능 검증을 위해 잠깐 사용하는 것이니 인터페이스에 조회기능 까지 추가하지는 말자.

이제 test 폴더 아래 hello.core.singleton 패키지에 ConfigurationSingletonTest 클래스를 만들고 다음과 같이 코드를 작성하자.

- ConfigurationSingletonTest.java

public class ConfigurationSingletonTest {

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

        // 구현체를 타입으로 넣은 이유는 해당 구현체에 작성해둔 get 메소드를 활용하기 위해서이다.
        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);
    }
}

결과 : 테스트 통과

memberService -> memberRepository1 = hello.core.member.MemoryMemberRepository@1838ccb8
orderService -> memberRepository2 = hello.core.member.MemoryMemberRepository@1838ccb8
memberRepository = hello.core.member.MemoryMemberRepository@1838ccb8

 

결과를 확인해보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용된다.

- AppConfig 의 자바 코드를 보면 분명히 각각 2번 new MemoryMemberRepository 를 호출해서 다른 인스턴스가 생성되어야 하는데 어째서일까?

- 혹시 두번 호출이 안되는 것은 아닌지 실험을 통해 알아보자.

 

AppConfig 에 다음과 같이 코드를 작성해보자.

- AppConfig.java

@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 FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

memberService(), orderService(), memberRepository() 각각의 메소드를 호출할 때 로그를 남기기 위해 출력문을 작성해주었다.

이렇게 코드를 작성해놓고 configurationTest() 를 다시 수행시켜 보면 memberService() 호출 1개, orderService() 호출 1개, memberRepository() 호출 3개가 나오지 않을까 생각할 수도 있다.

그런데 실행 결과를 보면 다음과 같이 출력되는 것을 확인할 수 있다.

 

결과 :

23:51:23.788 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberService'
call AppConfig.memberService
23:51:23.801 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberRepository'
call AppConfig.memberRepository
23:51:23.803 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'orderService'
call AppConfig.orderService

 

호출 결과를 확인해보면 각 빈이 한번씩 만 호출되어 생성 되었다는 것을 확인할 수 있다.

스프링이 어떻게든 싱글톤 패턴을 지켜주고 있는 것이다.

어떻게 이런게 가능할까?

 

 

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

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

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

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

 

ConfigurationSingletonTest 클래스에 다음과 같이 코드를 추가해보자.

- ConfigurationSingletonTest.java

public class ConfigurationSingletonTest {

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

        // 구현체를 타입으로 넣은 이유는 해당 구현체에 작성해둔 get 메소드를 활용하기 위해서이다.
        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);
    }

    // @Configuration 바이트 코드 시험
    @Test
    void configurationDeep(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        AppConfig bean = ac.getBean(AppConfig.class);

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

+ 참고 : 사실 AnnotationConfigApplicationContext 에 파라미터로 넘긴 값도 스프링 빈으로 등록된다. 그래서 AppConfig 도 스프링 빈이 된다.

 

이와 같이 AppConfig 스프링 빈을 조회해서 클래스 정보를 출력하는 configurationDeep() 메소드를 추가하고 해당 메소드를 실행시켜 보면 아래와 같은 결과를 얻을 수 있다.

결과 :

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$293b8ddb

 

그런데 순수한 자바 클래스라면 다음과 같이 출력 되어야 한다.

bean = class hello.core.AppConfig

 

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

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

그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다. 아마도 다음과 같이 바이트 코드를 조작해서 작성되어 있을 것이다.(실제로는 CGLIB 의 내부 기술을 사용하는데, 매우 복잡하다.)

- @Bean 이 붙은 메소드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환한다.

- 스프링 빈이 존재하지 않으면 기존에 AppConfig 에 작성되어 있는 객체 생성로직을 실행한 다음, 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.

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

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

 

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

@Configuration 을 붙이면 바이트 코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean 만 적용하면 어떻게 될까?

- AppConfig.java

// @Configuration 삭제
public class AppConfig {
}

이제 똑같이 configurationDeep() 메소드를 실행해보면 아래와 같은 결과가 출력되는 것을 확인할 수 있다.

결과 :

call AppConfig.memberService
call AppConfig.memberRepository
00:23:32.898 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'orderService'
call AppConfig.orderService
call AppConfig.memberRepository
00:23:32.901 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberRepository'
call AppConfig.memberRepository
00:23:32.901 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'discountPolicy'
bean = class hello.core.AppConfig

 

이 출력 결과를 통해서 AppConfig 가 CGLIB 기술 없이 순수한 AppConfig 로 스프링 빈에 등록된 것을 확인할 수 있다.

또한 MemberRepository 가 총 3번 호출된 것을 알 수 있다. 1번은 @Bean 에 의해 스프링 컨테이너에 등록하기 위해서이고, 2번은 각각 memberRepository() 를 호출하면서 발생한 코드이다.

 

이 상태로 configurationTest() 메소드를 실행하면 당연히 만들어진 3개의 memberRepository 빈 객체가 모두 같은 참조값을 가지고 있지 않기 때문에(서로 다른 객체이기 때문에) 테스트 통과에 실패하는 것을 확인할 수 있다.

+ 참고 : 여기서 getMemberRepository() 메소드를 통해 만들어진 MemberRepository 는 스프링 빈 이라고 볼 수 없다. 사실상 new MemoryMemberRepository() 코드를 직접 실행시킨 것이다.

즉, 스프링 컨테이너가 관리하지 않는 객체라는 것이다.

확인이 끝났으면 @Configuration 이 동작하도록 다시 돌려놓자.

 

 

정리

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

    - memberRepository() 처럼 의존관계 주입이 필요해서 메소드를 직접 호출할 때 싱글톤을 보장하지 않는다.

- 크게 고민할 것이 없다. 스프링 설정 정보는 항상 @Configuration 을 사용하자.