Singleton Container
웹 애플리케이션과 싱글톤
-
스프링은 기업용 온라인 서비스 기술을 지원하기 위한 도구
-
웹 애플리케이션은 보통 여러 고객이 동시에 요청
-
스프링 없는 순수한 DI 컨테이너인 AppConfig 는 요청시마다 객체로 새로 생성
- 메모리 낭비가 심하다.
- 해결방안: 해당 객체가 딱 1개만 생성되고 공유하도록 설계 → 싱글톤 패턴
싱글톤 패턴
- 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
- 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
public class SingletonService {
private static final SingletonService instance = new SingletonService();
public static SingletonService getInstance() {
return instance;
}
private SingletonService() { // private 생성자로 생성 막기
}
}- static 영역에 객체 instance 를 미리 하나 생성해서 올려둔다.
- 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회 가능
- 이 메서드를 호출하면 항상 같은 인스턴스 반환
- 딱 1개의 객체 인스턴스만 존재해야 하므로 생성자를 private 으로 막는다.
- 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.
싱글톤 패턴 테스트 케이스
@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {
SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();
System.out.println("singletonService1 = " + singletonService1);
System.out.println("singletonService2 = " + singletonService2);
Assertions.assertThat(singletonService1).isSameAs(singletonService2);
// isSameAs(): ==
// isEqualTo(): equals()
}- isSameAs()
- ==
- isEqualTo()
- equals()
💡 스프링 컨테이너를 쓰면 컨테이너가 기본적으로 객체를 다 싱글톤으로 만들어서 관리
- 싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라 이미 만들어진 객체를 공유해서 효율적으로 사용
싱글톤 패턴의 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많아진다.
- 의존관계상 클라이언트가 구체 클래스에 의존한다. → DIP 위반
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
- 테스트 하기 어렵다.
- 내부 속성을 변경하거나 초기화 하기 어렵다.
- private 생성자로 자식 클래스를 만들기 어렵다.
싱글톤 컨테이너
- 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 1개만 생성
- 객체 인스턴스를 싱글톤으로 관리
- 스프링 빈이 싱글톤으로 관리되는 빈
- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
- 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
- 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결, 객체를 싱글톤 유지 가능
- 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
- DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤 사용 가능
싱글톤 컨테이너 적용 후
- 스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용 가능
참고: 스프링의 기본 빈 등록 방식은 싱글톤이지만 싱글톤 방식만 지원하는 것은 아니다.
요청할 때마다 새로운 객체를 생성해서 반환하는 기능도 제공
싱글톤 방식의 주의점
- 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태 유지 (stateful) 하게 설계하면 안된다.
- 무상태 (stateless) 로 설계해야한다.
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
- 가급적 읽기만 가능해야 한다.
- 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
- ⚠️스프링 빈의 필드에 공유 값을 설정하면 큰 장애 발생
💡 스프링 빈은 항상 무상태 (stateless) 로 설계 ⭐
🧑🏻💻 Hello World!