싱글톤 컨테이너

• 웹 애플리케이션과 싱글톤

  • 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다.
  • 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다! 메모리 낭비가 심하다.
  • 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. 싱글톤 패턴 필요이유

• 싱글톤 패턴, 컨테이너

  public class SingletonService {
  
    private static final SingletonService instance = new SingletonService();
  
    public static SingletonService getInstance() {
        return instance;
    }
  
    private SingletonService() {
  
    }
  
    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
  }
  
  

  • 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.

이러한 문제점을 스프링은 어떻게 보완하였을까?

• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.

• 싱글톤 방식의 주의점

  @Test
  void statefulServiceSingleton() {
      ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
      StatefulService statefulService1 = ac.getBean(StatefulService.class);
      StatefulService statefulService2 = ac.getBean(StatefulService.class);
  
      //ThreadA: A사용자 10000원 주문
      int userAPrice = statefulService1.order("userA", 10000);
      //ThreadB: B사용자 20000원 주문
      int userBPrice = statefulService2.order("userB", 20000);
  
      //ThreadA: 사용자 A 주문 금액 조회
      System.out.println("price = " + userAPrice);
  
      // Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }
  
  

  • StatefulService 의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다

• @Configuration과 싱글톤, 바이트코드 조작의 마법

  • @Configuration 사용할 때 : 결과 -> (한번씩 호출) call AppConfig.memberService, call AppConfig.memberRepository, call AppConfig.orderService
  • @Configuration 사용 안할 때 : 결과 -> call AppConfig.memberService, call AppConfig.memberRepository, call AppConfig.orderService, call AppConfig.memberRepository, call AppConfig.memberRepository
  • @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.
  • 크게 고민할 것이 없다. 스프링 설정 정보는 항상 @Configuration 을 사용하자.