싱글톤 컨테이너

기존에 스프링 없이 작성한 DI 컨테이너 AppConfig를 사용하면 사용자의 요청이 들어올 때마다 객체들을 하나씩 계속해서 생성한다.

 

사용자의 요청이 매우 많은 웹 애플리케이션에서 이같은 구조는 비효율적이다.

 

이를 해결하기 위해 싱글톤 디자인패턴을 활용한다.

 

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

객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다

public class SingletonService {

    // 하나만 존재하도록 하기 위해 static으로 선언
    private static final SingletonService instance = new SingletonService();

    // 객체의 외부 생성을 막기 위해 생성자 private 설정
    private SingletonService() {}

    // 이 클래스의 인스턴스가 필요하다면 getInstance()를 통해서만 접근할 수 있다
    public static SingletonService getInstance() {
        return instance;
    }
}

 

그럼 이제 AppConfig에서 객체를 생성하는 모든 함수들에 getInstance() 를 적용시켜 주면 된다.

 

하지만 싱글톤 패턴에도 여러 가지 단점이 존재한다.

 

1. 싱글톤 패턴 구현을 위한 추가 코드들 작성해야함

2. AppConfig 없이 싱글톤만 사용할 경우 클라이언트가 서버 객체의 구체 클래스에 의존하게 되어 OCP, DIP가 위반된다. (SingletonService.getInstance() -> static 메서드를 사용하기 위해 어쩔 수 없이 구체 클래스에 의존하게 된다)

3. 객체 내부 속성을 변경하거나 초기화하기 어렵다.

4. 유연성이 떨어진다

 

등등..

 

 

 

스프링 컨테이너를 사용하면 싱글톤 패턴의 장점은 모두 챙기면서 단점은 모두 피할 수 있게 된다.

 

 

 

(싱글톤 패턴 사용 시 주의점)

모든 사용자들의 요청을 하나의 빈이 수행하기 때문에 아래와 같은 사항들을 주의해야 한다.

1. stateless로 설계해야 한다.

2. 가급적 읽기만 가능해야 한다.

3. 스프링 빈의 필드에 공유 값을 설정하면 장애가 발생할 수 있다.

 

 

 

 

출처 : www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard