섹션5. 싱글톤 컨테이너

웹 애플리케이션

• 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있다.
• 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.
• 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다.
• 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다 -> 메모리 낭비가 심하다.
• 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다 -> 싱글톤 패턴

싱글톤 패턴이란?

• 객체의 인스턴스가 오직 1개만 생성되도록 보장하는 패턴
• private 생성자를 사용해서 외부에서 new 키워드로 새로운 객체 인스턴스를 만들지 못하도록 막아야 한다.

단점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다.
• DIP를 위반한다. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다.
• 안티패턴으로 불리기도 한다.

해결 방법, 싱글톤 컨테이너

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

싱글톤 방식의 주의점

• 싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.
• 무상태(stateless)로 설계해야 한다.
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다 -> 사용자의 주문금액이 다른 사람의 주문금액과 바뀔 수 있음

@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();
       }
... 
}

• 각각 다른 2개의 MemoryMemberRepository 가 생성되면서 싱글톤이 깨지는 것 처럼 보인다 -> 결과적으로 memberRepository 인스턴트는 모두 같은 인스턴스가 공유되어 사용된다.

@Configuration과 바이트 코드 조작

• 스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 저 자바 코드를 보면 분명 3번 호출되어야 하는 것이 맞다. 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

1. AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 스프링 빈으로 등록된다
2. AppConfig 도 스프링 빈이 된다 -> 정확히는 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConifg클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록하게 된다.
3. 변경된 AppConfig@CGLIB 클래스는 memberRepository()로 memoryMemberRepository 객체를 만들 때 이미 스프링 컨테이너에 등록 되어 있으면 해당 컨테이너에서 찾아서 반환한다.
4. 스프링 컨테이너에 없다면 기존 로직을 호출해서 MemoryMemgberRepository를 생성하고 스프링 컨테이너에 등록한다.