싱글톤 패턴, 싱글톤 컨테이너

웹 애플리케이션은 보통 여러 고객이 동시에 요청하는데 요청할 때마다 스프링 없는 순수한 DI 컨테이너는 객체를 생성해 준다.

@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer() {
    AppConfig appConfig= new AppConfig();
    //1. 조회 : 호출할 때 마다 객체를 생성
    MemberService memberService1 = appConfig.memberService();
    //2. 조회 : 호출할 때 마다 객체를 생성
    MemberService memberService2 = appConfig.memberService();

    //참조값이 다른 것을 확인    
    Assertions.assertThat(memberService1).isNotSameAs(memberService2);

}

이는 고객의 트래픽이 많아지면 메모리 낭비가 심해진다.

이를 해결하기 위해 객체가 1개만 생성되고 공유하도록 설계를 해야 한다.

 

싱글톤 패턴

객체가 딱 1개만 생성되는 싱글톤 패턴을 적용해 보자

객체 인스턴스를 여러 개 생성하지 못하도록 private 생성자를 사용해서 외부에서 new 키워드를 사용하는 것을 막고 내부에서 인스턴스를 하나만 생성한다.

SingletonService라는 예제 class를 만들어 테스트해보자

public class SingletonService {
    
    // static이여서 클래스 레벨에 올라 딱 하나만 존재한다
    private static final SingletonService instance = new SingletonService(); 

    //getInstance 함수를 이용해야지만 인스턴스를 얻을 수 있다.
    public static SingletonService getInstance() {
        return instance;
    }
    //생성자는 private로 만든다.
    private SingletonService() {
    }
    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

테스트 코드를 작성해 보자

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {
    SingletonService singletonService1 = SingletonService.getInstance();
    SingletonService singletonService2 = SingletonService.getInstance();
    assertThat(singletonService1).isSameAs(singletonService2);
}

 

테스트 결고 같은 인스턴스라고 뜬다.

하지만 싱클톤 패턴에는 많은 문제점이 있다.

 

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드를 작성해야한다.
• DIP를 위반한다.
• OCP 원칙을 위반할 가능성이 높다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.

싱근톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 인스턴스를 하나만 만들어 관리한다.

스프링의 기본 빈 등록 방식은 싱글톤 방식이지만 싱글톤 방식만 지원하는 것은 아니다.

 

출처 : 인프런 스프링 핵심 원리 - 기본 편  김영한