스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생하였다.
대부분의 스프링 애플리케이션은 웹 애플리케이션이고, 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.
스프링 없는 순수한 DI컨테이너인 AppConfig는 요청을 할때마다 객체를 새로 생성한다.
즉, 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다. → 메모리 낭비
해결방안은 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 된다. ⇒ 싱글톤 패턴
싱글톤 패턴
싱글턴 패턴(Singleton pattern)을 따르는 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다.
- 클래스의 인스턴스가 딱 한개만 생성되는 것을 보장하는 디자인 패턴.
- 한 jvm, 한 자바 서버 안에서는 그 객체 인스턴스가 딱 하나만 생성. - 그래서 객체 인스턴스를 두개 이상 생성하지 못하도록 막아야 한다.
- private 생성자를 사용해서 외부에서 임의로 new키워드를 사용하지 못하도록 막아야한다.
static영역에 객체를 딱 한개만 생성해둔다.
이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
딱 한개의 객체 인스턴스만 존재해야 하므로 생성자를 private로 막아서 혹시라도 외부에서 new키워드로 객체 인스턴스가 생성되는 것을 막는다.
싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다.
하지만 문제들도 있음
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- 의존관계상 클라이언트가 구체 클래스에 의존한다. → DIP 위반
- 클라이언트가 구체 클래스에 의존해서 OCP원칙을 위반할 가능성이 높다.
- 테스트하기 어렵다.
- 내부 속성을 변경하거나 초기화하기 어렵다.
- private생성자로 자식 클래스를 만들기 어렵다.
- 결론적으로 유연성이 떨어진다.
⇒ 스프링 프레임워크는 싱글톤 패턴의 문제점을 해결하면서 객체를 싱글톤으로 관리해준다!
