[Spring 기본] 싱글톤 컨테이너 (1)

♪ 학습 내용 

 

싱글톤 패턴 및 싱글톤 컨테이너

---

* 싱글톤

 

웹 애플리케이션은 특성상 여러 고객이 동시에 요청을 한다

 

만약 DI컨테이너인 AppConfig에서 여러 고객이 동시에 요청을 한다면

 

각 요청마다 새로운 객체 인스턴스를 생성해버린다

 

매우 낭비..!!

 

싱글톤 패턴 : 객체가 딱 1개만 생성되고 공유하도록 설계

 

싱글톤 패턴 적용

- static 영역에 객체를 1개 미리 생성해둔다

 

- 그 객체는 getInstance()메서드를 통해서만 접근 가능

 

- private으로 생성자 제한. 외부에서 new 연산자로 객체를 생성하지 못한다

 

즉, 여러 호출이 들어와도 같은 객체 인스턴스를 반환. 싱글톤 패턴.

싱글톤 패턴 테스트 - 같은 객체 인스턴스가 반환되었는지 확인한다 - 결과 : 성공

 

싱글톤 문제점

 

- 코드가 늘어남

- 구현에 의존 ( 클라이언트에서 구체클래스.getInstance를 사용하게 되는) DIP위반 가능

- OCP 위반 가능

 

* 싱글톤 컨테이너

 

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결, 객체 인스턴스를 싱글톤으로 관리(싱글톤 레지스트리)

 

정말인지 바로 확인해보자

 

스프링 컨테이너가 싱글톤 지원하는지 확인

컨테이너에서 같은 이름, 타입으로 빈 조회하여 memberService 1 / 2 각각 생성.

 

만약 스프링 컨테이너가 싱글톤 레지스트리 기능을 지원하지 않는다면 서로 다른 memberService 객체가 반환되어

 

isSameAs 에서 오류 발생할 것이다.

 

결과는 ??

 

성공

즉, 스프링 컨테이너는 자동으로 객체를 한 개만 생성하고 관리하는 기능을 가진다. → 싱글톤 컨테이너

 

그림으로 표현하면 다음과 같다

 

Bean등록 시 싱글톤으로 객체 하나 생성 후 관리한다

이미 만들어진 객체를 공유해서 효율적으로 재사용 가능

 

여기서 또 스프링을 사용하는 이유를 알 수 있다.

 

전처럼 AppConfig를 DI컨테이너로 직접 생성하여 싱글톤 패턴까지 적용할려면 매우 귀찮고 피곤

 

하지만 이처럼 스프링 컨테이너를 통해 객체를 자동으로 관리하면 얼마나 편안한가.

 

솔직히 말하자면 싱글톤 직접 구현하다가 스프링이 자동으로 해주는 걸 알았을때 정말 감탄했다

 

스프링은 신인가..?

 

---

♪ 다음 학습 내용 

 

객체 인스턴스를 하나만 생성해 공유하는 싱글톤 방식의 주의점

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의