싱글톤 컨테이너

만약 고객이 메서드를 요청해서 객체를 생성하는데, 고객이 10000명이면 10000개의 객체를 생성해야 될것이다. 하지만 많은 고객이 요청을 몇번이나 하던 같은 객체에서 요청을 처리해 주는것이 싱글톤의 개념이다.

위와 같이 매번 객체를 생성하면 메모리 낭비가 심할 것이다.

이것을 해결하는 방법이 객체를 1번만 생성한 후 이것을 공유하는 개념인 싱글톤 패턴이다.

1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
2. 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드만을 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
3. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

getInstance() 메서드로 똑같은 SingletonService 객체가 호출되었다.

하지만 싱글톤 패턴들의 문제점도 있다.

1. 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
2. 의존관계상 클라이언트가 구체 클래스에 의존한다. -> DIP를 위반한다.
3. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
4. 테스트하기 어렵다.
5. 내부 속성을 변경하거나 초기화 하기 어렵다.
6. private 생성자로 자식 클래스를 만들기 어렵다.
7. 결론적으로 유연성이 떨어진다.
8. 안티패턴으로 불리기도 한다.

이러한 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리하는것이 스프링 컨테이너이다.
이때까지 했던 스프링 빈이 바로 싱글톤으로 관리되는 빈이다.

싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.

위에서 같은 객체를 호출하는것을 볼 수 있다.

• 스프링 컨테이너 덕분에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.