싱글톤 컨테이너

 

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다.

 

 

 

▶ 싱글톤이란 무엇이고, 왜 쓰게 되었는가?

1. 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 만들어졌음
2. 대부분의 스프링 애플리케이션은 웹 애플리케이션 (다른 애플리케이션도 충분히 개발할 수는 있음)
3. 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 함
4. 만약, 고객 트래픽이 초당 100이 나오면 초당 100개의 객체가 생성되고 소멸됨 (메모리 낭비가 심함!)
5. 해결방안 : 해당 객체가 1개만 생성되고, 공유하도록 설계해야 함 → 싱글톤 패턴의 등장

 

 

▶ 스프링 활용 이전의 싱글톤 방식

public class SingletonService {

    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance() { return instance; }

    private SingletonService() {}

    public void logic() { System.out.prinln("싱글톤 객체 로직 호출"); }
    
}

• static 영역에 객체 instance를 미리 하나 생성해서 객체 인스턴스를 2개 이상 생성하지 못하도록 막는 방식
• 딱 1개의 객체 인스턴스만 존재해야하므로, 생성자를 private으로 막아서 혹시라도 외부의 new 키워드로 객체 인스턴스가 생성되는 것을 막음
• 문제점 : 구현 코드가 많이 들어감 / 클라이언트가 구체 클레스에 의존 (DIP 및 OCP 위반 가능성) / 유연하게 테스트하기 어려움 / 내부 속성을 변경하거나 초기화하기 어려움 / private 생성자로 자식 클래스를 만들기 어려움

=> 결론적으로 유연성이 떨어지며, 안티패턴이라 불리기도 함

 

 

 

▶ 스프링의 싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리 (스프링 빈이 바로 싱글톤으로 관리되는 빈)
• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리
• 스프링 컨테이너는 싱글톤 컨테이너의 역할을 함 (이렇게 싱글톤 객체를 생성하고 관리하는 것을 '싱글톤 레지스트리'라고 부름)
• 싱글톤 패턴이 기존에 갖고 있었던 모든 단점을 해결하면서 객체를 싱글톤으로 유지 (지저분한 코드X, DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있게 됨)

다음 예시 코드를 보면, 스프링 컨테이너 덕분에 싱글톤 관련 코드 없이 싱글톤을 사용할 수 있다는 것을 알 수 있다.

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
    //Appconfig appConfig = new AppConfig();
    ApplicationContext ac = new AnnotationConfigApplicationContext(Appconfig.class);

    MemberService memberService1 = ac.getBean("memberService", MemberService.class);
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);

    System.out.println("memberService1 = " + memberService1);
    System.out.println("memberService2 = " + memberService2);

    assertThat(memberService1).isSameAs(memberService2);
}

 

▶ 싱글톤 방식의 주의점

• 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태유지(stateful) 대신 무상태(stateless)로 설계해야 함
• 특정 클라이언트에 의존적인 필드가 있으면 안됨
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됨
• 읽기만 가능 / 변경은 불가능해야 함
• 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 함
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있음

※ @Bean만 사용해도 스프링 빈으로 등록되지만 싱글톤을 보장하지 않음

→ 고민할 필요 없이 @Configuration 등록