[스프링 핵심 원리 - 기본편] #5. 싱글톤 컨테이너

[chaelink]

섹션 5 싱글톤 컨테이너

1. 웹 애플리케이션과 싱글톤

대부분의 스프링 애플리케이션은 웹 애플리케이션이며, 배치 애플리케이션과 데몬 애플리케이션도 일부 있다.

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 보낸다
따라서, 고객이 요청을 할 때 마다 새로 객체를 생성하면 메모리 낭비가 엄청나게 된다
이런 문제를 해결하기 위해 객체를 딱 1개만 생성하고 공유하는 싱글톤 패턴을 사용한다

스프링이 있다면 어떻게 되는 지 궁금해서 혼자 한번 끄적여봤다

2. 싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

public class SingletonService {

    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();

    //2. public으로 열어서, 객체인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 한다.
    public static SingletonService getInstance() {
        return instance;
    }

    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    private SingletonService() {
    }

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

싱글톤 패턴을 구현하는 방법은 여러가지가 있으며, 우리는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택했다.

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하기 위해 많은 코드를 작성해야한다
• 클라이언트가 구체 클래스에 의존한다(getInstace)
• • DIP를 위반한다, OCP 원칙을 위반할 가능성이 높다
• 테스트하기 어렵다
• 내부 속성을 변경하거나 초기화하기 어렵다
• private 생성자를 사용하였으므로 자식 클래스를 만들기 어렵다
• 유연성이 떨어진다 => 안티패턴으로 불리기도 한다

3. 싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리한다

싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않고 싱글톤으로 관리한다. => 모든 담점 커버
  • 컨테이너 생성 과정을 보면, 컨테이너는 객체를 하나만 생성해서 관리한다.
  • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
  • DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.

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

        //호출할 때 마다 같은 객체를 반환
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);

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

        assertThat(memberService1).isSameAs(memberService2);
    }

참고 : 스프링의 기본 빈 등록 방식은 싱글톤이지만, 싱글톤 방식만 지원하는 건 아님

4. 싱글톤 방식의 주의점

여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다.

무상태로 설계해야 한다

• 특정 클라이언트에 의존적인 필드가 있으면 안된다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. -> 읽기만 가능해야 한다
• 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);

        StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
        StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);

        statefulService1.order("user1", 10000);
        statefulService2.order("user2", 20000);

        int price = statefulService1.getPrice();

        System.out.println("price = " + price);

    }

    static class TestConfig{

        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }

}

5. @configuration과 싱글톤

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public DiscountPolicy discountPolicy() {return new RateDiscountPolicy();
    }
}

memberService 와 orderService 에서도 memberRepository()를 호출하여, 결과적으로 싱글톤이 깨지는 것처럼 보인다

테스트를 해보자

@Test
 void configurationTest() {
 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

 MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
 OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
 MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

 //모두 같은 인스턴스를 참고하고 있다.
 System.out.println("memberService -> memberRepository = " + memberService.getMemberRepository());
 System.out.println("orderService -> memberRepository = " + orderService.getMemberRepository());
 System.out.println("memberRepository = " + memberRepository);

memberRepository는 모두 같은 인스턴스가 공유되고 있다.

AppConfig를 통해 확인해보자

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        System.out.println("call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        System.out.println("call AppConfig.orderService");
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        System.out.println("call AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        System.out.println("call AppConfig.discountPolicy");
        return new RateDiscountPolicy();
    }
}

6. @configuration과 바이트코드 조작의 마법

어떻게 위에서 본 것같은 결과가 나왔을까?
@configuration을 적용한 AppConfig에 비밀이 있다.

public class ConfigurationSingletonTest {
    @Test
    void configurationDeep() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        
        //AppConfig도 스프링 빈으로 등록된다.
        AppConfig bean = ac.getBean(AppConfig.class);

        System.out.println("bean = " + bean.getClass());
        //출력: bean = class hello.core.AppConfig$$SpringCGLIB$$0
    }
}

• AppConfig도 스프링 빈이 된다.
• 순수한 클래스가 아닌 CGLIB 등이 붙어있다.

CGLIB이라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들어 스프링 빈으로 등록하였다.

AppConfig@CGLIB은 AppConfig의 자식 타입이므로, AppConfig 타입으로 조회 할 수 있다

@configuration을 적용하지 않고 @bean만 적용하면 어떻게 될까?

• 다음과 같이 싱글톤은 보장되지 않는 것을 확인할 수 있다.
• CGLIB 기술 없는 순수한 AppConfig가 스프링 빈에 등록되었다.