AppConfig 같은 커스텀 DI컨테이너는 수많은 요청이 들어오면 그때마다 객체를 많이 만들게끔 된다!

해당 객체가 하나만 생성되게끔 만들자! → 싱글톤 패턴! → 알지?

private static final Singletone instance = new Singletone()

와 같이 생성자 private으로 수정 막고 static영역으로 올려서 다 쓸 수 있게끔 만들어서 하나만 쓸 수 있게끔!!!

무조건 조회는 getSingletone()로만 접근하게끔!

Singletone instance1 = Singletone.getInstance();

Singletone instance2 = Singletone.getInstance();

→ 두 개 다 이미 static에 올려놓은 같은 객체(DI 컨테이너)를 참조중! 즉 객체 생성 한번만!

근데?!!!? 스프링 컨테이너는 Bean들을 싱글톤으로 관리하고 있다 그래서 싱글톤 컨테이너라고도 함!! 게임 만들때처럼 귀찮게 할 필요 없겠네 ~ (스프링의 기본 빈 등록 방식은 싱글톤 방식(99%)이지만, 꼭 싱글톤 방식만 제공하는 것은 아님!! 요청할 때마다 새로운 객체를 생성하여 제공하는 것도 있음. 상황에 맞게끔 설정.)

그래서 아래 코드와 같이 두개 참조한거 getBean으로 가져와보면 참조 주소 객체가 같음!

public class SingletonTest {

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

        MemberService memberService1 = ac.getBean("memberService",MemberService.class);
        MemberService memberService2 = ac.getBean("memberService",MemberService.class);

        //참조값이 같은 것을 확인
        System.out.println("memberService1: " + memberService1);
        System.out.println("memberService2: " + memberService2);

        //memberService1 == memberService2
        Assertions.assertThat(memberService1).isSameAs(memberService2);

    }
}

중요!! 싱글톤 방식의 주의점!

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