"스프링 핵심 원리 - 기본편" 강의를 수강중입니다. 학습한 내용을 정리하고 있습니다.

싱글톤 개요

• 어떤 클래스의 인스턴스가 정확히 한 개여야 할 때 사용합니다.

• 그 클래스의 인스턴스를 사용하는 코드는 모두 같은 인스턴스에 접근하게 됩니다.

싱글톤으로 해결하고자 하는 문제

• 웹 서버의 경우 사용자의 요청이 올 때마다 서버의 코드가 실행됩니다.

  • 이 때 사용자의 요청이 올 때마다 클래스의 인스턴스를 생성하고 가비지컬렉션으로 제거하는 것보다, 재사용할 수 있는 인스턴스는 재사용하는 것이 경제적입니다.

문제 해결 1 - 싱글톤 패턴

• 미리 인스턴스를 만들어놓을 것인지, 실행 시 동적으로 필요 시 인스턴스를 만들 것인지에 따라서 싱글톤 패턴에도 여러 종류가 존재합니다.

  • 다음은 전자에 대한 예시 코드입니다.

    public class Singleton {
        private Singleton() {}
        private static final Singleton instance = new Singleton();
        public static Singleton getInstance() { return instance; }
    }

• 싱글톤 패턴의 문제

   

  • 싱글톤으로 관리하고자 하는 모든 클래스 코드에 싱글톤 패턴의 코드를 추가해야 합니다.

     

  • 클라이언트가 구체 클래스에 의존하게 되어 OCP, DIP를 위반할 가능성이 높습니다, 테스트하기 어렵습니다.

    • 스프링을 안 쓸 때 이 문제를 해결하려면, 앞의 DI에서 한 것과 마찬가지로 클라이언트는 추상적인 인터페이스에 의존하도록 하고, DI를 활용하여 싱글톤 인스턴스를 주입하는 코드만 구체 클래스에 의존하도록 구성하면 해결할 수 있습니다.

       

  • 내부 속성의 초기화가 어렵습니다.

    • 필요한 내부 속성의 종류가 컴파일 시점에 정해져 있으면 내부 속성 종류별로 하나씩 싱글톤을 만들어야 할 것 같습니다.

    • 필요한 내부 속성의 종류가 컴파일 시점에 정해져 있지 않으면 싱글톤 패턴을 사용하면 안 될 것 같습니다.

  • 내부 속성의 변경이 어렵습니다.

  • 자식 클래스를 만들기 어렵습니다.

문제 해결 2 - 스프링 컨테이너

• 스프링 컨테이너의 경우 앞의 싱글톤 패턴의 문제점들을 해결해줄 수 있습니다.

  • 특히 보일러플레이트의 문제를 해결해줄 수 있습니다.

• 동작 방식

  • 스프링 컨테이너의 경우 기본적으로 스프링 빈을 싱글톤 객체로 관리해줍니다.

    • 이 때 각 클래스에 싱글톤 패턴을 적용하지 않아도 스프링 빈에서의 인스턴스는 동일하게 관리됩니다.

• 동작 원리

  • 의문: 각 클래스에 싱글톤 패턴을 적용하지 않았고, 클래스의 인스턴스를 생성하는 함수를 여러 번 호출하였는데도 어떻게 싱글톤 인스턴스가 생성되는 것일까요? -> @Configuration 어노테이션

  • 스프링에서 @Configuration 어노테이션이 붙은 클래스를 상속받는 하위 클래스를 만들고 이를 사용한다.

    • 하위 클래스 예상도: @Bean 어노테이션이 달린 부모 클래스의 메소드들을 오버라이딩해서, 이미 빈이 등록되어 있으면 그 인스턴스를 반환하고, 없으면 부모 클래스의 메소드를 호출해서 빈으로 등록하는 코드가 적용되어 있을 것이다.

싱글톤 컨테이너 사용시 주의사항

• 각 컨테이너를 무상태(stateless)로 만들어주어야 합니다!!!