왜 싱글톤?
-(기존) 클라이언트가 요청할때마다 객체가 생성 -> 메모리 낭비
-해결책: 해당 객체를 한개만 생성하고 공유하도록 설계
-클래스의 인스턴스가 딱 1개만 생성되는것을 보장하는 디자인 패턴
-e.g. static 영역에 객체 instace를 미리하나 생성하고 getInstance()메서드를 통해서만 조회
-생성자를 private 막아서 new 키워드로 객체 인스터스가 생성되는것을 막음
-하나의 객체만을 쓰기 때문에 시스템 효율증가
-단점
- DIP 위반(클라이언트가 구체 클래스에 의존) e.g. 구체클래스.메서드()
- OCP 위반
- 테스트하기 어려움(설정이 이미 끝남)
- 유연성이 떨어짐
싱글톤 컨테이너
-싱글톤 패턴의 모든 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리(스프링 빈 객체)
-스프링 컨테이너는 싱글톤 컨테이너임(싱글톤 레지스트리: 싱글톤 생성 및 관리)
-스프링 컨테이너 덕분에 이미 만들어진 객체를 공유해서 효율적으로 재사용 가능
싱글톤 방식의 주의점(실무에서 매우 중요)
-하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게(stateful) 설계하면 안됨
-무상태하게 설계(stateless)
-가급적 Read만 가능
-특정 클라이언트 의존 X
-특정 클라이언트가 값을 변경 할수 X
-지역변수, 파라미터, ThreadLocal등을 사용
-공유값 설정 X
'웹 프로그래밍 > 스프링' 카테고리의 다른 글
의존관계 자동 주입 (0) | 2023.02.17 |
---|---|
컴포넌트 스캔 (0) | 2023.02.16 |
스프링 컨테이너와 스프링 빈 (0) | 2023.02.14 |
IoC, DI, 컨테이너 (0) | 2023.02.14 |
AppConfig (0) | 2023.02.14 |