🎯 목표 : Singleton 패턴과 스프링 Singleton 컨터에너에 대한 이

📒 Singleton Pattern

📌 Why

• 스프링을 사용하지 않고 Java로만 구현한 Config DI 컨테이너는 요청할때마다 새로 객체를 생성한다.
• 100번 요청되면 100개의 객체가 생성되고 소멸되는 과정이 필요할 것이다.
• 이런 문제점을 개선하기 위해 객체는 1개만 생성되고 1개의 객체로 공유하는 패턴인 싱글톤 패턴을 사용하게 된다.

---

📌 Singleton

• 클래스의 인스턴스가 딱 하나만 생성되는 것을 보장하는 디자인 패턴이다.

public class SingletonService {
//1. static 영역에 객체를 하나만 생성한다.
	private static final SingletonService instance = new SingletonService();

//2. public static으로 이미 생성된 객체를 반환받는 방식으로 만든다.
    public static SingletonService getInstance() {
   		return instance;
    }

//3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    private SingletonService() {
    }

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

• 테스트 코드로 만들어 실행 해보면 두번의 객체를 호출했음에도 같은 객체인 것을 확인할수 있다.

    @Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용")
    public void singletonServiceTest() {
	//private으로 생성자를 막아두어. 컴파일 오류가 발생한다.
	//new SingletonService();
        //호출할 때 마다 같은 객체를 반환
        SingletonService singletonService1 = SingletonService.getInstance();
        //호출할 때 마다 같은 객체를 반환
        SingletonService singletonService2 = SingletonService.getInstance();

        //참조값이 같은 것을 확인
        System.out.println("singletonService1 = " + singletonService1);
        System.out.println("singletonService2 = " + singletonService2);

        // singletonService1 == singletonService2
        assertThat(singletonService1).isSameAs(singletonService2);
    }

// 출력값
singletonService1 = hello.core.singleton.SingletonService@192c3f1e
singletonService2 = hello.core.singleton.SingletonService@192c3f1e

---

📌 Singleton의 한계

• 예제에서 구현해본 싱글톤 패턴의 문제점은 무엇일까?
• 우선, 구현하는데 코드작성이 필요하다. 지금은 최대한 간단히 구현 했지만, 다양한 방법으로 구현 할수 있고 여러 기능들을 추가하게 된다면 복잡해 질 것이다.
• 객체를 요청할때, 구현체의 메소드를 호출하여 객체를 얻을수 있음으로 클라이언트가 구현체 클래스에 의존하게된다.
  DIP 설계 원칙을 위반 하게 되며, OCP 설계 원칙도 위반할 여지가 높아진다.
• 이미 초기화 되어 있고 생성자도 막아 놔, 클래스 내부 속성을 변경하거나 초기화 하기 어려우며 상속에 대한 유연성이 아주 떨어진다.
• 안티패턴으로 불린다.

---

📒 Singleton Container

📌 Singleton의 한계 극복

• 싱글톤 컨테이너는 싱글턴 패턴을 구현하지 않아도 객체의 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 하며 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• 스프링 컨테이너는 모든 싱글톤 패턴의 단점을 해결하면서 객체의 싱글톤을 유지할 수 있다.
• 패턴을 구현하기 위한 복잡한 구현 코드가 필요없다.
• DIP, OCP, 테스트, 상속으로 부터 자유롭다.

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

        // 조회 1
        // 조회 2
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);
        // 참조값 확인
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);
        // =
        Assertions.assertThat(memberService1).isSameAs(memberService2);
    }

    //출력값
    memberService1 = hello.core.member.MemberServiceImpl@52d239ba
    memberService2 = hello.core.member.MemberServiceImpl@52d239ba

• 위 코드에서 따로 싱글톤을 구현한 것은 없다. AppConfig.class는 의존관계 관리를 위해 Bean들을 등록 해두었다고 가정한다.

---

📌 Singleton의 설계

• 스프링 컨테이너에서의 싱글톤 객체든, 싱글톤 패턴을 구현한 객체든 인스턴스 하나로 공유하는 방식이기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다. 무상태 설계를 해야한다 \= stateless
• 클라이언트에 의존적인 필드가 있어서는 안된다.
• 클라이언트가 값을 변경할수 있는 필드가 있으면 안된다.
• \= 읽기만 가능해야한다.

// StatefulService.java
public class StatefulService {
    private int price;

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

    }
    public int getPrice() {
        return price;
    }
}

// StatefulServiceTest.java
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주문
        statefulService1.order("userA",10000);
        // ThreadA B 사용자 20000주문
        statefulService2.order("userB",20000);

        //A의 주문 금액 조회
        int price = statefulService1.getPrice();
        System.out.println("price = " + price); // 20000

        // 같은 객체기 때문에 10000원으로 할당되었던 price의 값이 20000으로 바뀜
        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);

    }

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

• 위 코드에서 스프링 컨테이너에서 싱글톤을 유지해주는 기능 때문에 발생하는 문제를 확인 할수 있다.
• userA가 스프링 컨테이너에서 제공하는 StatefulService 인스턴스를 받아 10000원의 주문을 했다고 가정하자.
• 싱글톤 객체이기 때문에 StatefulService 의 order 메소드를 호출하며 필드의 price 값은 10000원이 될것이다,
• userB가 동시에  StatefulService 인스턴스를 받아 20000원의 주문을 했다고 가정하자. 같이 order 메소드를 호출 했기 때문에 필드의 price 값은 20000원이 될것이다.
• userA와 userB가 공유한 StatefulService 인스턴스는 같은 인스턴스다. 코드의 흐름으로 봤을때 StatefulService 인스턴스의 필드멤버 price 값은 최종적으로 20000이 되어 있을것이다. 

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

• userA의 getPrice 값을 비교 했는데 20000이 나왔다. 상태를 유지하는 객체를 설계하게 되면 이러한 심각한 문제가 발생 할수도 있다.
• StatefulService 클래스는 아래와 같이 개선 하게 되면 정상적으로 동작 하게된다.

public class StatefulService {

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

---

📒 Singleton 과 @Configuration

📌 @Configuration

• 의존 관계를 설정해주던 AppConfig 의 코드를 보면 궁금한점이 생긴다.
• memberRepository()가 2번 호출 됨으로서 new MemoryMemberRepository()도 2번 호출 되는 것이 아닌가?
• 그렇다면 2개의 MemoryMemberRepository 객체가 생성되어야 하는것이 아닌가?

@Configuration
public class AppConfig {
    @Bean
    public MemberService 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 RateDiscountPolicy();
    }
}

• 각 Bean에 메소드명 출력 로그를 남기고 아래 테스트를 해보면 확인 할수 있다.

    @Test
    void configurationTest() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();
        System.out.println("memberRepository1 = " + memberRepository1);
        System.out.println("memberRepository2 = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);

        AppConfig appConfig = ac.getBean(AppConfig.class);
        System.out.println("appConfig = " +appConfig.getClass());

        Assertions.assertThat(memberRepository1).isSameAs(memberRepository);
        Assertions.assertThat(memberRepository2).isSameAs(memberRepository);

    }

    // 출력값
Call AppConfig.memberService
Call AppConfig.memberRepository
Call AppConfig.orderService
memberRepository1 = hello.core.member.MemoryMemberRepository@68044f4
memberRepository2 = hello.core.member.MemoryMemberRepository@68044f4
memberRepository = hello.core.member.MemoryMemberRepository@68044f4
appConfig = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$30511a3f

• 모든 MemoryMemberRepository 객체는 같은 객체로 확인 된다.
• 모든 Bean은 한번씩만 호출 되는 것을 볼수 있다.
• appConfig 의 출력 값을 보면,
• 스프링 컨테이너는 순수한 AppConfig 객체를 생성하는 것이 아닌 CGLIB이 붙은 AppConfig를 상속받은 임의의 클래스를 만들고 이 임의의 클래스를 스프링 빈으로 등록해 놓은 것이다.
• CGLIB라는 바이트 조작 라이브러리를 사용하여 등록된 스프링 빈의 임의의 인스턴스는 어떤 기능을 할까?
• AppConfig@CGLIB는 등록된 Bean들의 인스턴스를 생성하고 싱글톤이 보장되도록 해준다.
• 위 코드와 같이 new MemoryMemberRepository()가 중복 호출 되더라도 스프링 컨테이너에서 동일한 Bean이 있다면 해당 Bean을 반환 해주고, 없다면 Bean으로 등록해주는, 동적으로 동작한다.