[Spring] @Configuration, @Bean의 동작 방식(싱글톤)

@Configuration, @Bean

Spring에서 Bean을 수동으로 등록하기 위해서 설정 클래스 위에 @Configuration 어노테이션을 추가하고, @Bean을 사용해 수동으로 빈을 등록, 관리할 수 있게 된다.

 

이때 내부적으로 어떤식으로 동작하는지 확인하면서 @Configuration과 @Bean을 파헤쳐보는 것을 목적으로 한다.

해당 글은 김영한님의 온라인강의 [스프링 핵심 원리 - 기본편]의 내용을 기반으로 작성하였습니다.

---

 

@Configuration / @Bean

 

 

• 수동으로 스프링 컨테이너에 Bean을 등록하기 위한 어노테이션이다.
• 1개 이상의 @Bean을 제공하는 클래스의 경우 반드시 @Configuration을 명시해 주어야 싱글톤이 보장된다.
• 유지보수성을 높이기 위해 애플리케이션 전범위적으로 사용되는 클래스나 다형성을 활용하여 여러 구현체를 빈으로 등록할 때 사용한다.

 

스프링 컨테이너는 @Configuration이 붙어있는 클래스를 자동으로 빈으로 등록해두고, 해당 클래스를 파싱해서 @Bean이 있는 메소드를 찾아 빈을 생성해준다. 

 

@Bean 어노테이션은 @Configuration 어노테이션과 함께 사용해야 싱글톤을 보장받을 수 있으므로 @Bean 어노테이션은 반드시 @Configuration 어노테이션과 함께 사용해주어야 한다.

 

 

 

@Configuration과 싱글톤

 

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

}

 

위 코드를 보면 조금 이상해 보일 수 있다.

 

memberService 빈을 만드는 코드를 보면 memberRepository()를 호출한다.

이 메소드를 호출하면 new MemoryMemberRepository()를 호출한다.

 

orderService 빈을 만드는 코드도 동일하게 memberRepository()를 호출한다.

이 메소드를 호출하면 new MemoryMemberRepository()를 호출한다.

 

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

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

 

/* memberService */
public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

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


/* orderService */
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;

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

위 처럼 테스트를 위해 MemberRepository를 조회할 수 있는 기능을 추가해주었다.

 

이제 테스트 코드를 작성해 보자

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

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

 

테스트를 실행해 보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용되는 것을 알 수 있다.

 

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

 

 

스프링 컨테이너는 AppConfig에 각각 @Bean이 호출해서 스프링 빈을 생성한다.

AppConfig의 call로그가 어떻게 찍히는지 확인해보자

출력 결과는 모두 1번만 호출된다.

 

 

 

@Configuration과 바이트코드

 

 

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

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

 

모든 비밀은 @Configuration에 있다.

 

다음 코드를 보자.

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

@Test
void configurationDeep() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    
    //AppConfig도 스프링 빈으로 등록된다.
    AppConfig bean = ac.getBean(AppConfig.class);

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

 

 

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

 

 

AppConfig@CGLIB 예상 코드

@Bean
public MemberRepository memberRepository() {

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

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

 

덕분에 싱글톤이 보장될 수 있는 것이다.

 

 

 

@Configuration 없이 @Bean만 적용하면 어떻게 될까?

 

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

//@Configuration 삭제
public class AppConfig {
	//...
}

 

이제 똑같이 아래 테스트코드를 실행해보면

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

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

위처럼 테스트도 오류가 발생하고 AppConfig의 memberRepository가 총 3번 호출된 것을 알 수 있다.

따라서 모두 다른 인스턴스 객체가 조회된다.

 

정리하자면 @Bean만 사용해도 스프링 빈으로 등록되긴 하지만, 싱글톤을 보장받지 못한다.

따라서 @Bean을 사용할때에는 꼭 Class에 @Configuration을 붙여 사용하도록 하자.