[Spring] 기본_싱글톤 컨테이너

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

• 애플리케이션은 보통 여러 고객이 동시에 요청함
• 이때, 우리가 만든 AppConfig는 고객이 요청할 때마다 객체를 new로 새로 만든다!!
• 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸 -> 메모리 낭비 심함 -> 1개 객체만 생성한 후 공유하면 됨(싱글톤)

@Test
@DisplayName("스프링 없는 순수한 DI컨테이너")  // 우리가 만들었던 순수한 DI컨테이너의 문제점 확인하기 위함
void pureContainer() {
    AppConfig appConfig = new AppConfig();

    // 1.조회: 호출할 때마다 객체 생성
    MemberSerivce memberSerivce1 = appConfig.memberService();

    // 2.조회: 호출할 때마다 객체 생성
    MemberSerivce memberSerivce2 = appConfig.memberService();

    // 참조 값이 다른 것을 확인
    System.out.println("memberSerivce1 = " + memberSerivce1);
    System.out.println("memberSerivce2 = " + memberSerivce2);
    
    // 다른 객체 가지고옴 -> 새로운 객체 생성 -> 이때 4개만들어짐
//        memberSerivce1 = hello.core.member.MemberServiceImpl@71e9ddb4
//        memberSerivce2 = hello.core.member.MemberServiceImpl@394df057
    Assertions.assertThat(memberSerivce1).isNotSameAs(memberSerivce2);  // 성공
}

• instance비교 : same, 수치비교 : equal

---

2. 싱글톤 패턴

public class SingletonService {

    // 자기 자신을 내부의 private static으로 설정하면 클래스 레벨에 올라가서 딱 하나만 만들어짐
    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance() {
        return instance;
    }

    private SingletonService() {
        // 외부에서 new키워드로 객체 인스턴스가 생성되는 것을 막음
    }

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

}

• 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 함
  • private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 함
  • 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회 가능
• 이렇게 하면 자바가 뜰 때 바로 singletonService의 static 영역의 오른쪽에 있는 new SingletonService()를 내부적으로 실행해서 객체(자기자신)을 생성해서 인스턴스에 참조 넣어둠
• 싱글톤 패턴 문제 생김!
  • 싱글톤 패턴을 구현하는 코드 자체가 많이 들어감(위의 코드가 매번 들어가야함)
  • 의존관계상 클라이언트가 구체 클래스에 의존하므로 DIP 위반
  • 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높음
  • 테스트하기 어려움
  • 내부 속성을 변경하거나 초기화 하기 어려움
  • private 생성자로 자식 클래스를 만들기 어려움
  • 결론적으로 유연성이 떨어짐

---

3. 싱글톤 컨테이너

• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리함
  • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 됨
  • DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있음
    

---

4. 싱글톤 방식의 주의점

• 객체 인스턴스를 하나만 생성해서 공유하는
  싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안됨
• 무상태(stateless)로 설계해야함
  • 특정 클라이언트에 의존적인 필드가 있으면 안됨
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됨
  • 가급적 읽기만 가능해야 함
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 함

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

[ test ]

class StatefulServiceTest {

    @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사용자 주문 금액 조회
        // 다른스레드에서 들어가도 동일한 객체이기 때문에 10000->20000로 바뀜
        int price = statefulService1.getPrice();

        // price = 20000 
        // why? A사용자가 가격을 정하기전에 B사용자가 들어왔기 때문
        System.out.println("price = " + price);  
    }

    static class TestConfig {

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

---

5. @Configuration과 싱글톤

@Configuration  // 만약, @Configuration이 없으면, 싱글톤X -> 계속 new MemoryMemberRepository()를 호출하는 것과 같음
public class AppConfig {

    @Bean  // @Bean을 통해 스프링컨테이너에 등록됨
    public MemberSerivce memberService() {
        System.out.println("call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());  // 생성자 주입
    }

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

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

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

• 내가 생각하는 진행상황
  • @Bean memberService -> new MemoryMemberRepository()
  • @Bean orderService -> new MemoryMemberRepository()
  • call AppConfig.memberService // memberService 호출
  • call AppConfig.memberRepository // memberService에서 memberRepository를 호출하면서 발생
  • call AppConfig.memberRepository // memberRepository 호출
  • call AppConfig.orderService
  • call AppConfig.memberRepository // orderService에서 memberRepository호출
• 실제 진행상황 : 싱글톤 보장
  • call AppConfig.memberService
  • call AppConfig.memberRepository
  • call AppConfig.orderService
• 
• @Configuration을 적용한 AppConfig는 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록함
• @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.