웹 애플리케이션과 싱글톤
➡️ 웹 애플리케이션은 보통 여러 고객이 동시에 요청
➡️ 스프링이 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체 새로 생성
➡️ 메모리 낭비
➡️ 해당 객체가 1개만 생성되고, 공유하도록 설계
➡️ 싱글톤 패턴
싱글톤 패턴
• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
• private 생성자 사용해 외부에서 new 키워드를 사용하지 못하도록 막아야 함
➡️ 싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다!
🔻 문제점
• 구현하는 코드 多
• 의존관계상 클라이언트가 구체 클래스에 의존 → DIP 위반, OCP 원칙을 위반할 가능성 ↑
• 테스트 어려움
• 내부 속성 변경 및 초기화 어려움
• Private 생성자로 자식 클래스 만들기 어려움
• 유연성 ↓
이를 해결해주는 것이 스프링 컨테이너!
스프링 컨테이너
• 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리
• 컨테이너 내에서 특정 클래스에 대해 @Bean이 정의되면, 그 클래스에 대해 딱 한 개의 인스턴스를 생성
• @Bean이 호출될 때마다 생성된 공유 인스턴스 리턴
• 싱글톤 객체를 생성하고 관리하는 기능 ➡️ 싱글톤 레지스트리
• 싱글톤 패턴의 단점을 해결하면서 객체를 싱글톤으로 관리 가능
✓ 코드 간단
✓ DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤 사용 가능
✨ 중요
싱글톤 객체는 유지(stateful)가 아닌 무상태(stateless)로 설계해야 한다!
• 특정 클라이언트에 의존적인 필드가 있으면 X
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 X
• 가급적 읽기만 가능해야 한다
• 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다
➡️ 스프링 빈의 필드에 공유 값을 설정하면 큰 장애가 발생할 수 있음
자바 싱글톤 vs 스프링 싱글톤
자바 싱글톤
클래스가 ClassLoader에 의해 단 한번만 인스턴스화 하는 것을 이용하여 구현 됨
• 생성자를 private 으로 선언: 외부에서 클래스의 오브젝트 생성 X
• 참조는 static 으로 정의: 어느 영역에서든 접근 가능
스프링 싱글톤
스프링 컨테이너에 의해 구현 됨
• 컨테이너 내에서 특정 클래스에 대해 @Bean이 정의되면, 스프링 컨테이너는 그 클래스에 대해 한 개의 인스턴스를 만듦
• 이 공유 인스턴스는 설정 정보에 의해 관리되고, bean이 호출 될 때마다 스프링은 생성된 공유 인스턴스를 리턴 시킴
