[Spring] 싱글톤 컨테이너

인프런의 <스프링 핵심 원리 - 기본편>을 듣고 공부 용도로 정리한 글 입니다. 

 

싱글톤

대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 특히 웹 애플리케이션에서는 보통 여러 고객이 동시에 요청을 한다.

스프링 없이 순수하게 만들었던 DI 컨테이너인 AppConfig를 생각해보면 요청을 할 때 마다 객체를 새롭게 생성한다는 것을 알 것이다.

그렇다면 고객 트래픽이 많아지면 그 만큼 객체가 생성되고 소멸되고 하게 되는데 이 경우는 메모리 낭비가 너무 심해지게 된다.

이를 위한 해결방안은 해당 객체를 딱 1개만 생성되게 하고 이를 공유하도록 하는 것이다. 이런 패턴을 싱글톤 패턴이라 한다.

 

 

싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 

객체를 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. -> private 생성자를 사용하여 외부에서 생성하지 못하도록 막는다. 

public class SingletonService {

    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();

    //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingletonService getInstance() {
        return instance;
    }

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

    }

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

싱글톤 패턴을 적용하게 되면 하나의 객체만 생성하고 요청이 들어올 때 마다 이를 공유해서 효율적으로 사용할 수 있지만 다음과 같은 많은 문저점들을 갖고있다. 

 

싱글톤 패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. (구체 클래스의 get~~으로 가져와야 하기 때문에) -> DIP 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• priavte 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다.
• 안티 패턴으로 불리기도 한다.

 

싱글톤 컨테이너

스프링 컨테이너는 위의 문제점들을 해결하면서, 싱글톤으로 관리한다.

-> 이것이 AppConfig를 직접 사용하는 것보다 스프링 컨테이너를 사용하는 장점이다. 

즉, 싱글톤 패턴의 모든 단점을 해결하면서도 객체를 싱글톤으로 유지할 수 있다.

 

* 주의점 *

싱글톤 패턴에서는 하나의 같은 객체 인스턴스를 공유하기 때문에 상태를 유지(stateful)하게 설계해서는 안된다!

무상태(stateless)로 설계해야 한다!

 

 

@Configuration과 싱글톤

앞서 AppConfig 작성할 때 @Configuration 어노태이션을 붙여줬던 것이 기억날 것이다.

이것은 왜 붙여줬을까? @Configuration 이 바로 싱글톤 패턴이 가능하도록 하기 때문이다.

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

    @Bean
    public MemoryMemberRepository memberRepository() {
        System.out.println("call AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }

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

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

위 코드를 보면 이상한 점이 있다. 코드 상으로는 memberService 빈을 만들면서 new MemoryMemberRepository() 가 호출되고,

orderService 빈을 만들면서 또 다시 new MemoryMemberRepository() 가 호출된다. 그럼 같은 객체를 2번 만들었으니 싱글톤이 깨진 것이 아닌가? 이것이 @Configuration을 붙여주는 이유이다. @Configuration을 사용하면 객체가 1번만 생성된다. 

 

어떻게 이것이 가능할까?

AppConfig 설정 정보로 스프링 컨테이너를 만들면 AppConfig 역시 스프링 빈에 등록된다. 실제 AppConfig 스프링 빈을 조회해보면 다음과 같이 나온다.

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

순수한 클래스 형식으로 나오지 않는다. CGLIB가 붙은 복잡한 형태로 나온 것을 확인할 수 있다.

그 이유는 스프링 컨테이너에 실제 AppConfig가 등록된 것이 아닌 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해

AppConfig를 상속받은 임의의 다른 클래스를 만들고 스프링 빈으로 등록했기 때문이다.

이 임의의 클래스가 싱클톤이 보장되도록 해준다.

 

AppConfig@CGLIB 예상 코드를 봐보자

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

스프링 컨테이너에 빈이 등록되어 있으면 스프링 컨테이너에서 찾아서 반환해주고, 아니면 스프링 빈으로 등록하고 반환해준다.

 

@Configuration이 붙어야 CGLIB 기술을 사용해 싱글톤을 보장할 수 있다. 없다면 싱글톤을 보장하지 못하고 여러 객체 인스턴스를 만들게 된다.