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

안녕하세요!

이번에는 싱글톤에 관련해서 공부하고 왔습니다!

그럼 시작해보겠습니다.

고고!!

---

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

스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했습니다.

대부분의 스프링 애플리케이션은 웹 애플리케이션입니다.

몰론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있습니다.

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 합니다.

싱글톤 컨테이너 적용 전

1. 클라이언트 A, B, C가 memberService를 스프링한테 요청을 합니다.

2. 우리가 만들었던 DI 컨테이너(AppConfig)는 new로 memberService를 반환해줍니다.

=>A가 요청하면 DI 컨테이너가 반환해주고, B가 요청하면 DI 컨테이너가 또 반환해주고, C가 요청하면 DI 컨테이너가 또 반환해주고..

3. 이렇게 되면, 고객이 3번 요청을 하면 객체가 3개가 생성이 되는 것입니다.

 

근데, 이거.. 문제가 있습니다. 어떤 문제가 있냐면요..

웹 애플리케이션은 고객이 계속 요청을 하는 애플리케이션 입니다.

그래서, 계속 요청이 올 때마다 객체를 계속 만들어야 합니다.

이게 문제인 것입니다.

 

진짜 고객에게 요청이 올 때마다 이렇게 되나요?

스프링이 없는 순수한 DI 컨테이너 테스트 코드로 확인해보겠습니다.

 

우선, test 패키지에서 hello.core에 singleton이란 패키지를 만들고 그 안에 SingletonTest라는 자바 클래스를 만들도록 하겠습니다.

public class SingletonTest {

    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너")
    void pureContainer() {
        AppConfig appConfig = new AppConfig();
        //1. 조회: 호출할 때마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();

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

        //참조값이 다른 것을 확인
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);
    }
}

AppConfig (DI컨테이너)에 memberService를 2번 요청하면 과연 객체가 2개가 나올까요?

스프링이 없는 순수한 DI 컨테이너

결과 사진을 보면 appConfig한테 memberService를 달라고 할 때마다 다른 객체가 생성된다는 것을 알 수 있습니다.

 

검증을 한 번 해보도록 하겠습니다.

//검증
//memberService1과 memberService2는 달라야 한다.
Assertions.assertThat(memberService1).isNotSameAs(memberService2);

잘 되네요.

이런 식으로 요청이 들어올 때마다 객체가 계속 생성되는 것은 효율적이지 못하겠죠..?

 

우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성합니다.

고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸되는데, 이는 메모리 낭비가 심합니다.

해결 방안은 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 됩니다.

이것이 싱글톤 패턴!!

---

2. 싱글톤 패턴

싱글톤 패턴은 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴입니다.

그래서, 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 합니다.

막는 방법은 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 합니다.

코드로 한 번 봐보도록 하겠습니다.

 

아까 만들었던 test의 hello.core의 singleton 패키지에 SingletonService 자바 클래스를 만들어보겠습니다.

public class SingletonService {

    //자기 자신을 내부의 private로 하나 가지고 있는데, static으로 가지고 있습니다.
    //이렇게 하면 클래스 레벨에 올라가기 때문에 하나만 존재하게 됩니다.
    private static final SingletonService instance = new SingletonService();

    //조회
    public static SingletonService getInstance() {
        return instance;
    }

    //이렇게 싱글톤으로 해도 메인 함수에서 객체를 여러개 만들어버릴 수 있습니다.
    //그래서, private 생성자를 사용합니다. 생성을 막아버리려고.
    private SingletonService() {
    }

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

• private static final SingletonService instance = new SingletonService();
  • 1. static 영역에 객체를 딱 1개만 생성해둡니다.
  • 자기 자신을 내부의 private로 하나 갖고 있는데, static으로 갖고 있습니다.
    이렇게 하면 클래스 레벨에 올라가기 때문에 하나만 존재하게 합니다.
• public static SingletonService getInstance() {
      return instance;
  }
  • 2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용합니다.
• private SingletonService() { }
  
  • 3. 생성자를 private로 선언해서 new 키워드를 사용한 객체 생성을 하지 못하도록 막습니다.
• public void logic() {
     System.out.println("싱글톤 객체 로직 호출);
  }
  • 위에서 작성한 것들을 출력해보는 함수

<자세한 설명>

1. static 영역에 객체 instance를 미리 하나 생성해서 올려둡니다.

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

3. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막습니다.

 

싱글톤 패턴을 사용한 테스트 코드를 봐보도록 하겠습니다.

우선, singleton 패키지의 SingletonTest 클래스에서 밑에 마저 만들어보겠습니다.

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {
    new SingletonService();
}

new로 생성하려고 하면 어떻게 될까요?

private access 때문에 안 된다고 컴파일 오류를 딱 줘버립니다.

 

그럼 제대로 한 번 코드 작성을 해보겠습니다.

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {
    //조회
    SingletonService singletonService1 = SingletonService.getInstance();
    SingletonService singletonService2 = SingletonService.getInstance();

    System.out.println("singletonService1 = " + singletonService1);
    System.out.println("singletonService2 = " + singletonService2);
}

아까처럼 singletonService1,2 총 2개를 조회해볼건데요.

getInstance를 통해서만 조회할 수 있습니다.

 

결과가 어떻게 나올까요?

싱글톤 패턴을 적용한 객체 사용

엇!! 아까 싱글톤 적용 전과 다르게 이번엔 같은 객체를 가져왔다는 것을 알 수 있습니다.

같은 객체 인스턴스가 반환이 된거죠.

그럼 검증해보도록 하겠습니다.

assertThat(singletonService1).isSameAs(singletonService2);

위에서도 나왔는데 isSameAs와 isEqualTo의 정확한 차이점을 비교해보겠습니다.

🔥isSameAs vs IsEqualTo🔥

<isSameAs>
- 동일한 인스턴스인지 비교합니다. (자바에서 ==비교)
- 두 객체가 같은 메모리 주소를 참조하고 있는지 확인합니다.
ex) string a = new String("hello");
      string b = new String("hello");
      string c = a;

      assertThat(a).isSameAs(c); //✔️통과 (같은 객체)
      assertThat(a).isSameAs(b); //❌실패 (다른 객체지만 값은 같음)

⭐즉, 객체 참조 비교(==)입니다. 같은 인스턴스일 때만 통과해요.⭐

<isEqualTo>
-  equals() 메서드를 기준으로 비교합니다.
- 두 객체의 내용(값)이 같은지를 확인합니다.
- obj1.equals(obj2)가 true이면 통과합니다.
ex) string a = new String("hello");
      string b = new String("hello");
    
      assertThat(a).isEqualTo(b); //✔️통과 (내용이 같음)

⭐즉, 값 비교(.equals())입니다. 내용이 같으면 통과해요.⭐

오늘 한 것을 생각해보면 private로 new 키워드를 막아두었고, 호출할 때마다 같은 객체 인스턴스를 반환하는 것을 확인할 수 있습니다.

참고!! 싱글톤 패턴을 구현하는 방법은 여러가지가 잇습니다. 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택했습니다.

싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있습니다.

하지만, 싱글톤 패턴은 다음과 같은 수 많은 문제점들을 갖고 있습니다.

<싱글톤 패턴 문제점👻>

- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어갑니다.
- 의존 관계 상 클라이언트가 구체 클래스에 의존합니다. -> DIP 위반!!
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높습니다.
- 테스트 하기 어렵습니다.
- 내부 속성을 변경하거나 초기화 하기 어렵습니다.
- private 생성자로 자식 클래스를 만들기 어렵습니다.
- 결론적으로 유연성이 떨어집니다.
- 안티 패턴으로 불리기도 합니다.

이제, 싱글톤을 공부했으므로 AppConfig를 싱글톤으로 쫙 바꾸고 getInstance로 반환하는 작업을 해보면 되겠죠?

위의 단점을 보면 알겠지만, 사실 그럴 필요 없습니다.

스프링 컨테이너를 사용하면 기본적으로 객체를 싱글톤으로 만들어서 관리해주기 때문입니다.

---

3. 싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리합니다.

지금까지의 스프링 빈이 싱글톤으로 관리되는 빈입니다.

 

<싱글톤 컨테이너>

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

위에서 했던 SingletonTest 자바 클래스에서 테스트 코드를 마저 짜보도록 하겠습니다.

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
        
   //AppConfig appConfig = new AppConfig();
   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);

   //검증
   //memberService1과 memberService2는 같아야 한다.
   assertThat(memberService1).isSameAs(memberService2);
}

아까 위에서 했던 스프링을 사용하지 않은 pureContainer와 코드를 비교해서 보면 확실히 더 잘 보일 것입니다.

스프링 컨테이너와 싱글톤

같은 객체로 가져온 것을 확인할 수 있습니다.

 

아까 맨 처음의 그림에서 싱글톤 컨테이너를 적용한 후를 봐볼까요?

싱글톤 컨테이너 적용 후

1. 클라이언트 A, B, C가 memberService를 요청합니다.

2. 각자에게 동일한 memberService를 반환해줍니다.

 

스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하는 것이 아닌, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있습니다.

참고!! 스프링의 기본 빈 등록 방식은 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아닙니다.
요청할 때마다 새로운 객체를 생성해서 반환하는 기능도 제공합니다.
자세한 내용은 뒤의 빈 스코프에서 나올 예정입니다.

---

4. 싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(Stateful)하게 설계하면 안 됩니다.

즉, 무상태(Stateless)로 설계해야 합니다.

• 특정 클라이언트에 의존적인 필드가 있으면 안 됩니다.
• 가급적 읽기만 가능해야 합니다.
• 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 합니다.

스프링 빈의 필드에 공유 값을 설정하면 엄청 큰 장애가 발생할 수 이쒀요!!ㅠㅠ

 

상태를 유지할 경우 발생하는 문제점 예시 코드를 작성해보도록 하겠습니다.

Test 패키지에서 hello.core의 singleton 패키지에서 StatefulService 자바 클래스를 만들어보겠습니다.

public class StatefulService {

    //테스트 과정을 통해 10,000원->20,000원으로 바뀌어버림
    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;
    }
}

상태를 유지하는 가격이라는 필드를 만들었습니다. 이 가격 필드는 공유 필드 입니다.

그리고, 주문 함수를 만들었는데 여기서 this.price = price;가 문제가 됩니다.

왜인지는 테스트 해보면서 알아보도록 하겠습니다.

 

StatefulService에 대한 테스트를 만들어보겠습니다.

사실 그냥 Test 패키지의 hello.core의 singleton 패키지에서 걍 테스트를 생성해도 되지만 저희는 단축키를 한 번 써보도록 하겠습니다.

Window 기준 ctrl + shift + t를 누르면 밑에 사진처럼 나옵니다. (Mac은 command + shift + t)

쉽게 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 사용자가 10,000원 주문
        statefulService1.order("userA", 10000);

        //ThreadB: B 사용자가 20,000원 주문
        statefulService2.order("userB", 20000);

        //ThreadA: A 사용자 주문 금액 조회
        int price = statefulService1.getPrice();

        //ThreadA: A 사용자는 10,000원을 기대했지만 기대와 다르게 20,000원 출력
        System.out.println("price = " + price);
    }

    static class TestConfig {

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

A 사용자가 10,000원 주문을 호출하고, 본인이 주문한 금액을 조회하려고 했는데 그 사이에 B 사용자가 20,000원 주문을 해버립니다.

A 사용자가 주문한 금액을 조회하려고 하면 얼마가 나올까요?

Stateful 예시

예상했겠지만 20,000원이 나옵니다.

statefulService1이든 statefulService2든 들어가면 인스턴스는 같은 애로 인식을 해 버리기 때문에 중간에 20,000원으로 금액이 바뀌면 조회는 20,000원으로 됩니다.

 

검증을 해 보겠습니다.

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

statefulService1은 분명 10,000원이었는데 여기서 20,000원과 같다고 나오면 이 테스트는 싱글톤 방식을 잘못 사용했다는 뜻입니다.

한 번 해볼게요.

Stateful 예시

네 망했습니다. 이렇게 서비스 출시되면 안 돼요!

 

- 최대한 단순하게 보기 위해, 실제 쓰레드는 사용하지 않았습니다. (멀티 쓰레드 넘무 어려워ㅜㅅㅜ)

- ThreadA가 A 사용자 코드를 호출하고, ThreadB가 B 사용자 코드를 호출한다고 가정해보겠습니다.
=> StatefulService의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경합니다.
=> A 사용자의 주문 금액은 10,000원이 되어야 하는데, 20,000원이라는 결과가 나왔습니다.

=> 실무에서 이런 경우를 종종 보는데, 이로 인해 정말 해결하기 어려운 큰 문제들이 터집니다. (몇 년에 한 번씩 꼭 만납니다.)
=> 진짜 공유 필드는 조심해야 합니다. 스프링 빈은 항상 무상태(Stateless)로 설계해야 합니다!!

 

위의 상태유지(Stateful) 코드를 무상태(Stateless) 코드로 변경해보겠습니다.

따로 클래스는 만들지 않고, 위 클래스에서 작업하도록 하겠습니다.

StatefulService 자바 클래스로 이동해보겠습니다.

public class StatefulService {

    //private int price; //상태를 유지하는 가격이라는 필드 (Stateful 때 사용)

    //Stateful 때 사용
    /*
    public void order(String name, int price) {
        System.out.println("name = " + name + " price = " + price);
        this.price = price; //여기가 문제!!
    }
    */

    //공유 필드를 유지하지 않고, 함수를 void가 아닌 int로 해서 return price를 하면 됩니다.
    public int order(String name, int price) {
        System.out.println("name = " + name + " price = " + price);
        //this.price = price; //여기가 문제!!, Stateful 때 사용
        return price;
    }

    //Stateful 때 사용
   /* public int getPrice() {
        return price;
    } */
}

공유 필드를 유지하지 않고, 함수를 void가 아닌 int 로 해서 return price를 하면 됩니다.

 

StatefulServiceTest 자바 클래스로 이동해보겠습니다.

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 사용자가 10,000원 주문
        //statefulService1.order("userA", 10000); //Stateful 때 사용
        int userAPrice = statefulService1.order("userA", 10000);

        //ThreadB: B 사용자가 20,000원 주문
        //statefulService2.order("userB", 20000); //Stateful 때 사용
        int userBPrice = statefulService1.order("userB", 20000);

        //ThreadA: A 사용자 주문 금액 조회
       // int price = statefulService1.getPrice(); //Stateful 때 사용

        //ThreadA: A 사용자는 10,000원을 기대했지만 기대와 다르게 20,000원 출력
        //System.out.println("price = " + price); //Stateful 때 사용
        System.out.println("price = " + userAPrice);

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

    static class TestConfig {

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

무상태의 조건 중 하나가 지역변수 사용이 있었기 때문에 지역변수 userAPrice, userBPrice를 만들어줍니다.

이 상태에서 userAPrice를 조회하면 어떻게 될까요?

Stateless 예시

테스트가 잘 통과되었습니다.

지역변수는 공유되지 않기 때문이죠.

 

실무에서 이거 진짜 크게 문제가 되면 나의 결제내역, 로그인 정보가 다른 사람한테 보이고 하는거에요..ㄷㄷ

복구하는데 몇 달은 걸린다네요.

---

5. @Configuration과 싱글톤

@Configuration은 싱글톤을 위해 존재하는 것입니다.

코드를 봐보겠습니다.

 

AppConfig 자바 클래스로 이동해보겠습니다.

@Configuration
//설정 정보, 구성 정보
public class AppConfig {

    @Bean
    //각 메서드마다 @Bean 적어줌
    //이렇게 하면 스프링 컨테이너에 적용됨
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

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

memberService 부분을 봐보겠습니다.

@Bean이 있고 그 다음에 memberService를 하면 new로 MemberServiceImpl을 호출하고, memberRepository를 호출하면서 new MemoryMemberRepository를 호출해주게 됩니다.

 

그리고, orderService 부분을 봐보겠습니다.

@Bean이 있고 그 다음에 orderService를 하면 new로 OrderServiceImpl을 호출하고, memberRepository와 discountPolicy를 호출하면서 또 new MemoryMemberRepository를 호출해주게 됩니다.

 

어라? 2번 호출을 했네요?

이러면 싱글톤이 깨지는 것이 아닌가요?

 

직접 테스트를 해보겠습니다.

테스트 하는 방법은 간단합니다.

MemberServiceImpl에 있는 MemberRepository의 값을 확인해보면 됩니다.

 

MemberServiceImpl 코드로 이동해보겠습니다.

//테스트 용도
    public MemberRepository getMemberRepository() {
        return memberRepository;
    }

테스트 용도이므로 인터페이스까지 만들지는 않았습니다.

 

OrderServiceImpl 코드로도 이동해서 위에처럼 작성해보겠습니다.

//테스트 용도
    public MemberRepository getMemberRepository() {
        return memberRepository;
    }

MemberServiceImpl과 OrderServiceImpl 코드를 봐보면 둘 다 private final MemberRepository memberRepository;가 있는 것을 확인할 수 있습니다.

 

테스트 자바 클래스를 만들어보겠습니다.

test 패키지의 hello.core의 singleton 패키지에 ConfigurationSingletonTest 자바 클래스를 만들어보겠습니다.

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

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

분명 구체 클래스로 꺼내면 안 좋다고 했는데 왜 구체 클래스로 꺼내냐면..

Impl로 꺼내야 위에서 만들었던 getMemberRepository 함수를 불러올 수 있기 때문입니다.

마저 작성을 해보겠습니다.

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

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

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

MemberServiceImpl과 OrderServiceImpl 둘 다 MemberRepository를 불러오고, MemoryMemberRepository를 불러오기 때문에 구분을 짓기 위해서 memberRepository1, memberRepository2로 이름을 지었습니다.

과연 memberRepository1과 memberRepository2는 다른 애가 나올까요?

테스트를 실행해보겠습니다.

싱글톤 깨지는지 안 깨지는지 확인 (MemberServiceImpl, OrderServiceImpl 확인)

결과가 똑같게 나왔습니다.

 

검증을 하기 전에 한 가지 과정을 더 해보겠습니다.

Impl을 통해서 조회하는 것이 아닌, 진짜 MemberRepository를 조회해보겠습니다.

@Bean으로 등록되어있고, new로 MemoryMemberRepository를 리턴하기 때문에 아마 결과는 예상이 가는데요.

public class ConfigurationSingletonTest {
    
    @Test
    void configurationTest() {
        AnnotationConfigApplicationContext 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("memberService -> memberRepository = " + memberRepository1);
        System.out.println("orderService -> memberRepository = " + memberRepository2);
        //추가 테스트
        System.out.println("memberRepository = " + memberRepository);
    }
}

테스트를 실행해보겠습니다.

memberRepository 그 자체까지 확인

역시 3개의 스프링 빈은 다 똑같습니다.

검증도 해보겠습니다.

assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);

검증도 잘 맞습니다.

 

위에서 한 것들을 한 번 정리✏️해보겠습니다.

- 확인해보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용됩니다. (같은 애가 1번 생성)

- AppConfig의 자바 코드를 보면 분명히 각각 2번 new MemoryMemberRepository를 호출해서 다른 인스턴스가 생성되어야 하는데 어떻게 된 일 일까요? 혹시 2번 호출이 안되는 것일까요?

실험을 통해 알아보겠습니다.

 

AppConfig 클래스로 이동해보겠습니다.

@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 FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

이렇게 하면 결과는

call AppConfig.memberService -> call AppConfig.memberRepository -> call AppConfig.memberRepository -> call AppConfig.orderService -> call AppConfig.memberRepository 호출이 되어야 할 것 같습니다.

이렇게 memberRepository가 총 3번이 호출이 되어야 하구요.

 

몇 번 호출되는지 한 번 확인해보겠습니다.

ConfigurationSingletonTest 돌리면 됩니다.

이상합니다. 

결과가 call AppConfig.memberService 호출 후, call AppConfig.memberRepository 호출 후, call AppConfig.orderService가 호출되었습니다.

memberRepository가 3번 호출된 것이 아닌.. 1번 호출 되었습니다.

 

스프링이 어떻게든 싱글톤을 보장해주려고 한다는 것을 알 수 있습니다.

이것에 대한 자세한 설명은 밑에서 하도록 하겠습니다.

---

6. @Configuration과 바이트코드 조작의 마법

스프링 컨테이너는 싱글톤 레지스트리입니다.

따라서, 스프링 빈이 싱글톤이 되도록 보장해주어야 합니다.

 

그런데, 스프링이 자바 코드까지 어떻게 하기는 어렵습니다.

분명.. 위에서 한 자바 코드대로면 memberRepository가 3번 호출되어야 하는 것이 맞습니다.

그래서!!

스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용합니다.

모든 비밀은 @Configuration을 적용한 AppConfig에 있습니다.

 

위에서 만들었던 ConfigurationSingletonTest 자바 클래스로 가서 밑에 코드를 구현해보도록 하겠습니다.

@Test
void configurationDeep() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); //이 작업을 통해 스프링 빈으로 등록
    AppConfig bean = ac.getBean(AppConfig.class); //스프링 빈으로 등록된 AppConfig 조회
        
    //출력
    System.out.println("bean = " + bean.getClass());
}

사실 AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록됩니다.

그래서, AppConfig도 스프링 빈이 됩니다.

 

테스트를 실행해보겠습니다.

스프링 빈으로 등록된 AppConfig 조회

출력된 것을 보면 bean = class hello.core.AppConfig까진 예상한 대로 맞게 출력되었는데 그 뒤에 이상한게 있네여?

순수한 자바 클래스라면 class hello.core.AppConfig까지 출력되는게 정상인데 말입니다..

 

예상과는 다르게 클래스 명에 CGLIB 같은 것이 붙으면서 상당히 복잡해진 것을 볼 수 있습니다.

이것은 제가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속 받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것입니다.

 

말로는 복잡하니 그림으로 한 번 봐보도록 하겠습니다.

바이트코드 조작 라이브러리 사용

<그림에 대한 설명✏️>

1. 왼쪽 - 클래스 관계
- AppConfig: 우리가 작성한 원래 설정 클래스 (@Configuration이 붙은 클래스)
- AppConfig@CGLIB: 스프링이 런타임 시에 CGLIB를 이용해 생성한 프록시 클래스
👉🏻이 프록시가 실제 AppConfig를 상속하고, 내부 조직을 가로채서 동작을 제어합니다.

=> 화살표 방향은 AppConfig@CGLIB가 AppConfig를 상속(확장)하고 있다는 뜻입니다.

2. 오른쪽 - 스프링 컨테이너 내부
- 스프링 컨테이너는 원본 AppConfig 클래스의 인스턴스를 직접 사용하지 않습니다.
  대신, 프록시 객체(AppConfig@CGLIB)를 빈으로 등록해서 사용합니다.
- 이 프록시 객체는 메서드 호출을 가로채서 싱글톤 빈을 보장하는 등 다양한 동작을 가능하게 합니다.

ex) 위에서도 했던 예시인데, @Bean 메서드를 여러 번 호출해도 동일한 객체를 반환하게 처리하는 것도 이 CGLIB 덕분입니다.

아무튼, 그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해줍니다.

아마도 밑에처럼 바이트 코드를 조작해서 작성되어 있을 것입니다. (실제로는 CGLIB의 내부 기술을 사용하는데 매우 복잡합니다.)

 

<AppConfig@CGLIB 예상 코드>

...java
@Bean
public MemberRepository memberRepository() {
	
    	if (memboryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
        	return 스프링 컨테이너에서 찾아서 반환;
        }
        else { //스프링 컨테이너에 없으면
        	기존 로직을 호출해서 MemoryMemberRepository를 생성하고, 스프링 컨테이너에 등록;
            	return 반환;
        }
}
...

@Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어집니다.

덕분에 싱글톤이 보장되는 것입니다. (이 이유로 MemberRepository가 3번 호출되지 않고, 1번 호출된 것입니다.)

✔️참고!! AppConfig@CGLIB는 AppConfig의 자식 타입이므로, AppConfig 타입으로 조회할 수 있습니다.

 

6-1. @Configuration 적용하지 않고, @Bean만 적용하면?

@Configuration을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약에 @Bean만 적용하면 어떻게 될까요?

AppConfig 클래스에서 @Configuration을 빼고 ConfigurationSingletonTest 클래스의 configurationDeep 함수를 실행해보겠습니다.

@Configuration 제거 후 configurationDeep 함수 테스트한 결과

스프링 빈은 일단 다 등록이 됩니다.

그런데, 위에서 얘기했던 데로 memberRepository가 3번 호출되었습니다. 싱글톤이 깨진 것이죠.

1번은 @Bean에 의해 스프링 컨테이너에 등록하기 위해서이고, 2번은 각각 memberRepository()를 호출하면서 발생한 코드입니다.

그리고, 위에서 보였던 CGLIB가 안보이네요. 순수한 자바 코드 그대로 bean = class hello.core.AppConfig만 있습니다.

인스턴스가 같은지 테스트를 한 번 해보겠습니다.

위에서 테스트 한 클래스에서 configurationTest 함수를 돌려보면 됩니다.

어떻게 나올까요?

@Configuration 제거 후 configurationTest 함수 테스트 한 결과

위에서랑 다르게 @ 뒤에 부분이 셋 다 다른 것을 확인할 수 있습니다.

당연히 인스턴스가 같은지 테스트 하는 코드도 실패하고, 각각 다 다른 MemoryMemberRepository 인스턴스를 갖고 있는 것입니다.

그리고, 이렇게 되면 스프링 컨테이너가 관리하는 것이 아닌 제가 직접 new로 해서 넣은 것과 똑같습니다.

(문제 해결하려면 뒤에서 할건데 @Autowired MemberRepository memberRepository;를 해주면 됩니다.)

=> 의존관계 주입 끌어들이는 거에용

 

어찌되었든 확인이 끝났으면 @Configuration이 동작하도록 다시 돌려놓아야 합니다!!

<정리✏️>

- @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지는 않습니다.
👉🏻memberRepository()처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않습니다.
- 즉, 크게 고민할 것이 없습니다. 스프링 설정 정보는 항상 @Configuration을 사용하면 됩니다!!

 

---

오늘 공부도 이렇게 끝이 났습니다.

다음 섹션에서는 컴포넌트 스캔에 관련해서 할 예정입니다.

그럼 안뇽!!