싱글톤 컨테이너

💡 싱글톤 패턴

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

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

=> private 생성자를 사용해 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다

 

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

* getInstance() 메서드를 통해서 객체 인스턴스를 조회할 수 있다 + 항상 같은 인스턴스를 반환한다

* 1개의 객체 생성 -> 해당 객체 메서드 안에 집어넣기 -> 생성자 Private로 막기

 

❗️ 싱글톤 패턴 문제점

- 싱글톤 패턴으 구현하는 코드 자체가 많이 들어간다

- 의존관계상 클라이언트가 구체 클래스에 의존한다 => DIP 위반

- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다

- private 생성자로 자식 클래스를 만들기 어렵다 등 여러 문제점이 있다

 

💡 싱글톤 컨테이너

- 스프링 컨테이너는 싱클톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱클톤으로 관리한다

- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.

  이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다

* 고객의 요청이 들어올 때 마다 객체를 생성하는 것이 아니라,

  이미 만들어지 객체를 공유해서 효율적으로 재사용한다

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

-> 요청이 들어올 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다

 

❗️ 싱글톤 방식의 주의점

- 하나의 객체 인스턴스를 공유해서 사용하기 때문에,

  싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다

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

  : 특정 클라이언트에 의존적인 필드가 있으면 안된다

  : 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다

  : 가급적 읽기만 가능해야 한다

  : 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다

- 스프링 빈의 필드에 공유 값을 설정하면 안된다

 

* 스프링 빈은 항상 무상태(stateless)로 설계하자

 

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

* AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다

-> AppConfig도 스프링 빈이 된다

* @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 

   스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다

=> 싱글톤 보장

 

📌 정리

- @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다

  : memberRepository() 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다

- 그냥 스프링 설정 정보는 항상 @Configuration을 사용하자