배경

• 지금까지 스프링 없이 구현한 순수한 DI 컨테이너인 AppConfig는 요청할 때마다 객체를 새로 생성한다.
• 메모리 낭비가 심함
• 객체를 1개만 생성하고, 공유하도록 설계하면 된다.

Singleton Pattern

• Class의 instance가 딱 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() {
    }

싱글톤 패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 클라이언트가 구체 클래스에 의존한다. -> DIP 위반
• 그러므로 OCP 위반할 가능성이 높다.
• 결론적으로 유연성이 떨어진다.

Singleton Container

• Spring container는 singleton container의 역할을 한다.
• 싱글톤 패턴의 문제 해결 + 객체 인스턴스를 싱글톤으로 관리

주의점

• 싱글톤 객체는 Stateless하게 설계해야 한다.
• 특정 client에 의존적인 필드 X
• 특정 client가 값을 변경할 수 있는 필드 X
• 가급적 읽기만 가능해야 한다.

@Configuration과 싱글톤

@Configuration 참고
https://velog.io/@ssoyeong/Spring-Annotation-%EC%A0%95%EB%A6%AC#configuration

---

Reference
인프런 - 김영한님의 [스프링 핵심 원리 - 기본편] 수강 후 강의노트를 바탕으로 작성한 글입니다.