싱글톤 패턴의 개념

간단한 웹 사이트를 제작하고 고객에게 웹 사이트를 보낸다고 가정해보자.

만약 웹 사이트를 설계할 때 스프링 없는 DI 컨테이너를 요청할 때마다 객체를 계속 실행한다면 실행할 때마다 그만큼의 객체가 계속해서 생성된다. 즉, 100명의 고객이 웹 사이트를 들어오면 100개의 객체가 생성되어서 효율적이지 않다.

public class SingletonTest {

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

    // 2. 조회 : 호출할 때 마다 객체 생성
    MemberService memberService2 = appConfig.memberService();

    // 참조값이 다른것을 확인
    System.out.println("memberService1 = " + memberService1);
    System.out.println("memberService2 = " + memberService2);

    // memberService != memberService2
    Assertions.assertThat(memberService1).isNotSameAs(memberService2);
    // 스프링 없는 DI 컨테이너는 요청을 할 때마다 객체를 계속 실행한다.
    // 즉, 100명이 웹 사이트를 열면 그만큼의 객체가 계속해서 생성이 된다.
}
}

위와 같은 코드가 싱글톤 패턴을 지키지 않았을 경우이다.

 

 

싱글톤 패턴

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

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("싱글톤 객체 로직 호출");
    }
}

static 영역에 생성된 인스턴스를 조회할 방법은 getInstance()밖에 없다. 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막아서 딱 1개의 객체 인스턴스만 존재하게 된다.

 

테스트 코드에서 테스트 해 본 결과 같은 객체를 생성하는 것을 알 수 있다.

 

 

 

기존 싱글톤 패턴의 문제점

• 싱글톤 패턴은 구현하는 코드가 많이 들어간다.
• 의존관계상 구체 클래스에 의존 -> DIP를 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• prvate 생성자로 자식 클래스를 만들기 어려워서 유연성이 떨어진다.

 

 

 

스프링에서 제공하는 싱글톤 컨테이너를 사용하면 싱글톤 패턴의 문제점을 해결하면서 싱글톤을 잘 사용할 수 있도록 도와준다.