#7. 스프링의 싱글톤 컨테이너 (@Configuration)

해당 글은 김영한님의 인프런 강의를 공부하고 정리한 내용입니다.

 

 

# 웹 어플리케이션

• 스프링 프레임워크는 처음부터 기업용 온라인 서비스 기술지원을 타겟으로 탄생했다.
• 대부분의 스프링 앱은 웹이다. 물론 웹 말고 다른 앱을 만들 때 스프링을 사용해도 된다.
• 웹 어플리케이션은 보통 수 많은 사용자가 동시에 요청을 한다.

 

기존의 자바 코드를 이용하여 DI 컨테이너(AppConfig)를 구현한 경우, 고객의 요청할 때 마다 객체를 새로 생성하고 소멸한다. 그런데 DI 컨테이너를 굳이 이렇게 수백, 수만개를 만들었다가 소멸시킬 필요가 없을까? 이는 DI 컨테이너 객체를 하나만 만들어서 공유하도록 설계하면 된다. 이를 싱글톤 패턴이라 하며 스프링 컨테이너는 싱글톤 패턴을 사용한다.

 

---

# 싱글톤 패턴

그런데 싱글톤 패턴은 굳이 스프링이 아니더라도, 내가 직접 DI 컨테이너에 패턴을 적용할 수 있는 것 아닐까?

 

싱글톤 패턴은 스프링에서만 사용할 수 있는 개념이 아니다. 앞에서 서블릿의 동작과정을 배웠다면 알겠지만, 클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴이다. private 생성자를 사용해서 외부에서 new 키워드를 사용하지 못하게 막는다.

public class SingletonService {
    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    // 또는 getInstance() 호출 시, 현재 생성된 객체가 있는지 체크하여 만드는 방법도 있다.
    private static final SingletonService instance = new SingletonService();
   
   //2. getInstance()를 이용하여 객체를 반환한다.
    public static SingletonService getInstance() {
        return instance;
    }

    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    private SingletonService() {
    }

    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

하지만 싱글톤 패턴을 직접 구현했을 때 아래와 같은 문제점을 맞이하게 된다.

• 싱글톤 패턴을 구현하는 개발자의 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구현체 클래스에 의존한다. [ ...=구현체.getInstance() ] -> DIP, OCP 위반
• 테스트하기 어렵고, 상속도 어렵고, 내부 속성을 변경하거나 초기화하기 까다롭다.
• 즉 결과적으로 유연성이 떨어진다. (자주 사용되는 안좋은 코드, 안티패턴이라고 불리기도 한다.)

 

---

# 싱글톤 컨테이너

스프링 컨테이너는 개발자가 직접 싱글톤을 구현할 필요 없도록 만들어 싱글톤 패턴의 문제를 해결한다.  지금까지 우리가 사용한 스프링 빈은 전부 싱글톤으로 관리되는 빈이었다.

• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 기본적으로 싱글톤으로 객체의 인스턴스를 관리한다.
  - 컨테이너는 객체를 하나만 생성해서 관리한다.

  

• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 생성/관리하는 기능을 싱글톤 레지스트리라고도 한다.
• 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 단점을 해결하면서, 객체를 싱글톤으로 유지한다.
• 무엇보다 싱글톤 패턴을 위한 지저분한 코드가 필요없다.
• DIP, OCP, 테스트, Private 생성자로부터 자유롭게 싱글톤 패턴을 사용할 수 있다.

 

---

# 싱글톤 & 싱글톤 컨테이너 방식의 주의점

싱글톤 객체를 사용할 때, 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유한다는 사실을 까먹으면 안된다. 당연한 사실인 듯 해도 싱글톤 객체에 상태를 유지(Stateful)하도록 설계하는 실수를 종종 볼 수있다.

• 무상태(stateless)하게 설계해야한다.
• 특정 클라이언트에게 의존적인 필드가 있으면 안된다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
• 그래서 가급적 싱글톤 객체는 '읽기' 만 가능하도록 만들어야 한다.
• 필드 대신에 자바에서 공유되지 않는 지역변수, 파라메타, ThreadLocal등을 사용해야 한다

이를 유의하지 않고 스프링 빈의 필드에 클라이언트 간 공유 값을 설정하면, 정말 해결하기 어려운 큰 장애가 터지게 된다. 싱글톤 객체인 스프링 빈은 항상 무상태(Stateless)로 설계해야 함을 절대 까먹지 말자.

package hello.core.singleton;

public class StatefulService {
    private int price; //상태를 유지하는 필드

    public void order(String name, int price) {
        System.out.println("name = " + name + " price = " + price);
        this.price = price; //여기가 문제! 공유필드는 항상 조심해야 한다.
        // 실제 사용에서 주문 금액이 클라이언트간에 서로 영향을 끼치게 된다.
    }

    public int getPrice() {
        return price;
    }

 

---

# @Configuration과 싱글톤

아래 컨테이너 코드를 다시 살펴보자. 무언가 이상한 점이 있지 않은가?

• memberService 빈을 만드는 코드에 memberRepository()를 호출한다.
  - memberService Bean에 new MemoryMemberRepository가 생성된다.
• OrderService 빈을 만드는 코드에 memberRepository()를 호출한다.
  - OrderService Bean에 new MemoryMemberRepository가 생성된다.

그렇다. 결과적으로는 다른 2개의 빈에, 같은 구현체가 생성되며 싱글톤에 깨지는 것처럼 보인다. 스프링 컨테이너는 이 문제를 어떻게 해결했을까?

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
     ... 생략 ...
}

 

직접 실험을 통해 알아보자.

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

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

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

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

//콘솔 출력 결과. 놀랍게도 각각 1번만 호출된다.
call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService

 

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

스프링 컨테이너는 싱글톤 레지스트리이다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 하지만 위의 예제에서 알 수 있다싶이, 이를 자바 코드상에서 구현하기에는 매우 어렵다는 걸 알 수 있다. 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

 

모든 비밀은 @Configuration을 사용한 AppConfig에 있다. 사실 스프링 컨테이너의 구현체(AnnotationConfigApplicationContext)를 만들 때 파라메타로 넘긴 값은 스프링 빈으로 등록된다. 즉 AppConfig 가 스프링 빈이 된다는 말이다.

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

    // 순수한 클래스 Bean 의 출력 = class hello.core.AppConfig
    System.out.println("bean = "+bean.getClass());
    // 실제 콘솔창 출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70
    
}

하지만 콘솔창에 AppConfig를 찍어보면 알겠지만, AppConfig 빈 옆에 EnhancerBySpring CGLIB 라고 복잡하게 적혀있는 것을 볼 수 있다. 이는 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 [ AppConfig@CGLIB... ]를 만들고 이를 스프링 빈으로 등록한 것이다.

이해하기 쉽게 자바코드로 비유하자면, 아래와 같이 바이트코드를 생성한다고 생각하면 된다. 스프링은 @Bean이 붙은 메서드마다 스프링 빈이 존재하는지 확인 후, 없을 때만 생성하도록 바이트코드를 조작하여 싱글톤 객체를 보장한다.

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

 

# @Configuration을 적용하지 않으면요?

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

스프링의 @Configuration 설정은 바이트코드를 조작하는 CGLIB 기술을 사용하여 싱글톤을 보장한다. 만약 이를 적용하지 않고, @Bean만 사용하면 어떻게 될까?

// 어노테이션을 주석처리하였음.
// @Configuration
public class AppConfig {
	...
}

/* AppConfig를 콘솔에 출력한 모습.
  AppConfig bean=ac.getBean(AppConfig.class);
  System.out.println("bean = "+bean.getClass());
*/
bean = class hello.core.AppConfig

CGLIB 기술이 없이 순수한 AppConfig로 스프링 빈에 등록된다. 실제로 이렇게 사용하게되면 일반 자바코드와 다른게 없기 때문에, 위에서 말한 싱글톤 객체를 유지하지 못한다. 위의 예제를 다시 돌려보면 memberRepository를 호출한 만큼 객체를 새롭게 생성하는 것을 알 수 있다.

call AppConfig.memberService
call AppConfig.memberRepository // @Bean 최초 등록
call AppConfig.orderService
call AppConfig.memberRepository // OrderService -> memberRepository()
call AppConfig.memberRepository // MemberReposiotry -> memberRepository()

당연하게도 이렇게 Bean을 덮어씌우게되면 인스턴스가 같은지 테스트하는 코드는 정상작동 하지않는다. 왜냐하면 각각의 서비스마다 다른 memberRepository() 객체를 가지고 있기 때문이다.

 

 

---

# 모든 객체를 스프링 빈으로 만들면 좋을까요?

아니다. 재사용 할 일이 딱히 없는 객체나 스프링의 의존성 주입이 필요하지 않다면, 그냥 new로 생성해도 된다.

스프링에서는 아래와 같은 가이드라인을 제공한다.

 

👍 스프링 빈으로 등록해서 사용하면 좋은 경우

• 다른 객체의 의존성이 필요한 경우
• 다른 스프링 빈의 의존성으로 주입 되는 경우
• 스프링의 기능이 필요한 경우 (트랜잭션, 인터셉터, 프록시, SpringDataJpa등)

👎 스프링 빈으로 굳이 등록할 필요 없는 경우

• 위와 반대로 딱히 주입받거나 주입하는 객체가 없는 경우
• Spring의 기능이 딱히 필요없는 경우
• 대표적으로 Entity, DTO, Value Object 등

싱글톤 빈 내부에서 사용하는 객체의 경우, 어차피 new Object 로 생성하더라도 별 상관없다. (잘 생각해보면, 어차피 컨테이너가 1번 생성하고 계속 쓴다) 너무 스프링 빈에 집착하지는 말자.

 

 

# 결론

사실 어렵게 설명했지만, 결론은 스프링 설정 정보는 항상 @Configuration을 사용하자라는 말이다. 해당 어노테이션을 사용하면 스프링에서 어떤 방법을 써서라도 싱글톤 객체를 유지하게 해준다.