웹 애플리케이션과 싱글톤
- 보통 여러 고객이 동시에 요청
- 요청마다 객체 생성
- 요청이 증가할수록 객체 생성도 증가 -> 메모리 낭비 심함
- 해결 방안
- 해당 객체가 1개만 생성되고 공유하도록 설계
-> 싱글톤 패턴
- 해당 객체가 1개만 생성되고 공유하도록 설계
싱글톤 패턴
- 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
- 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 함
private생성자를 이용하여new키워드로 객체 인스턴스 생성 예방
싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다.
싱글톤 패턴 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다
- 의존관계상 클라이언트가 구체 클래스에 의존한다
- DIP 위반
- OCP 위반 가능성 증가
- 테스트하기 어렵다
- 내부 속성을 변경하거나 초기화하기 어렵다
private생성자로 자식 클래스를 만들기 어렵다- 유연성이 떨어진다
싱글톤 컨테이너
- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다
- 싱글톤 레지스트리: 싱글톤 객체를 생성하고 관리하는 기능
- 스프링 컨테이너 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다
- 싱글톤 패턴을 위한 코드 필요 없어짐
- DIP, OCP 위반 X
- 테스트,
private생성자로부터 자유롭게 사용 가능
싱글톤 컨테이너 적용 전
싱글톤 컨테이너 적용 후
싱글톤 방식의 주의점
- 싱글톤 객체틑 상태를 유지하게 설계하면 안된다
- 무상태로 설계해야 한다
- 특정 클라이언트에 의존적인 필드가 있으면 안된다
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다
- 가급적 읽기만 가능해야 한다
- 필드 대신에 자바에서 공유되지 않는 지역번수, 파라미터 등을 사용해야 한다
- 스프링 빈의 필드에 공유 값을 설정하면 큰 장애 발생 가능
고민중