Spring - 싱글톤 컨테이너(싱글톤 컨테이너, 싱글톤 방식의 주의점)

싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하며, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.
  • 지금까지 배웠던 스프링 빈이 싱글톤으로 관리되는 빈이다

싱글톤 컨테이너?

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

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

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

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

        assertThat(memberService1).isSameAs(memberService2);
    }

싱글톤 컨테이너 적용 후

• 스프링 컨테이너 덕분에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.
• 스프링의 기본 빈 등록 방식은 싱글톤이지만 싱글톤 방식만 지원하지는 않는다
  • 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다.

싱글톤 방식의 주의점

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

상태를 유지할 경우 발생하는 문제점 예시

package hello.core.singleton;

public class StatefulService {
    private int price; // 상태를 유지하는 필드

    public void order(String name, int price) {
        System.out.println("name = " + name + " price = " + price);
        this.price = price; // 이곳이 문제다!
    }
    public int getPrice() {
        return price;
    }
}

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);

        // Thread A : A 사용자 10000원 주문
        statefulService1.order("userA", 10000);
        // Thread B : B 사용자 10000원 주문
        statefulService1.order("userB", 20000);

        // Thread A : 사용자 A 주문 금액 조회
        int price = statefulService1.getPrice();
        // 예상헀던 결과는? price = 10000
        // 하지만 출력값은? price = 20000
        // A가 주문했던 10000원이 있었으나, B가 다시 주문해서 20000만원으로 바뀜
        // 객체의 상태가 유지되기 때문!
        System.out.println("price = " + price);

        assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

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

• 실제 쓰레드는 사용하지 않았다.
• Thread A가 사용자 A 코드를 호출, Thread B가 사용자 B의 코드를 호출한다 가정
• statefulService의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경
• 사용자 A의 실제 주문 금액은 10000원이어야 하는데 20000원이라는 결과가 나옴
• 공유필드는 조심해야 한다! 스프링 빈은 항상 무상태(stateless)로 설계하자

간단한 해결..?

   public int order(String name, int price) {
       System.out.println("name = " + name + " price = " + price);
       return price;
   }

  // Thread A : A 사용자 10000원 주문
  statefulService1.order("userA", 10000); // -> int userAPrice = statefulService1.order("userA", 10000);
  // Thread B : B 사용자 10000원 주문
  statefulService1.order("userB", 20000); // -> int userBPrice = statefulService1.order("userB", 20000);
  // int price = statefulService1.getPrice();

  // 출력값은? price = 10000 
  System.out.println("price = " + userAPrice);

출처 : 인프런 김영한 지식공유자님의 스프링 완전 정복 로드맵 강의