[Spring] 싱글톤 컨테이너

싱글톤 패턴

객체의 인스턴스가 딱 1개만 생성되어 공유되는 패턴을 의미한다.

인스턴스가 하나씩만 생성되므로 효율적인 메모리 관리가 가능하다.

객체가 호출됐을 때, 이미 만들어놓은 인스턴스를 공유함으로써 효율적인 재사용 또한 가능하다.

그러나 싱글톤 패턴은 ① 구현 코드가 많고, ② 의존관계상 클라이언트가 구체 클래스에 의존하여 DIP, OCP를 위반할 가능성이 높으며*, ③ 테스트하기 어렵단 이유 등으로 유연성이 떨어진다. 

public class SingletonService {

    public static final SingletonService instance = new SingletonService();
    ...
}

* 클라이언트가 구체 클래스(SingletonService)에 의존하며 DIP, OCP를 위반한다.

 

싱글톤 컨테이너

- 싱글톤 패턴의 단점을 보완하였다.

- 스프링 컨테이너는 싱글톤 컨테이너의 역할을 한다.

  이렇게 싱글톤 객체를 생성, 관리하는 기능을 싱글톤 레지스트리(Singleton Registry)라고 한다.

- 스프링 컨테이너를 사용함으로써 이제부턴 싱글톤 패턴 코드를 작성하지 않아도 된다. 클라이언트가 추상화에만 의존하므로 DIP, OCP를 준수하며, 테스트로부터 자유롭게 싱글톤을 사용할 수 있다.

 

싱글톤 방식의 주의점

무상태(stateless)로 설계해야 한다!

싱글톤 방식을 사용하면 여러 클라이언트가 하나의 객체 인스턴스를 공유한다. 이때 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안 된다. 하나의 객체를 공유하는 싱글톤 패턴의 특성상 상태가 공유되는 문제가 발생할 수 있다.

StatefulSerice.java

class StatefulService {

    private int price; //상태를 유지하는 필드 10000 -> 20000

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

    public int getPrice() {
        return price;
    }
}

StatefulSericeTest.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);
        //ThreadB : B 사용자 20000원 주문
        statefulService2.order("userB", 20000);

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

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

    static class TestConfig {

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

StatefulService의 order 메서드는 이름, 가격을 받아 price 변수에 저장한다.

StatefulServiceTest에서 사용자 A는 10,000원, B는 20,000원을 order 메서드에 넘겨줬을 때, StatefulService의 price는 10,000이 저장된 후 B가 주문한 정보를 넘기며 20,000으로 바뀐다.

따라서 사용자 A의 주문 금액을 조회하면 price에 마지막으로 저장된 20000이라는 잘못된 값이 반환된다.

실무에서 객체를 stateful하게 설계한다면, 로그인을 했을 때 다른 사람의 정보가 노출되는 등의 문제가 발생할 수 있다!!!🚨

따라서 객체는 무상태로 설계되어야 한다.

 

무상태로 설계한다는 것(stateless)은 상태를 공유하는 필드 변수가 없는 것을 의미한다. 다음 조건을 지키며 설계하자.

1. 특정 클라이언트가 의존적인 필드가 있으면 안됨
2. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됨
3. 가급적 읽기만 가능해야 함
4. 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야함

  * ThreadLocal : Thread 단위로 로컬변수 사용 가능

 

위 예제를 무상태로 설계하면 다음과 같다.

StatefulSerice.java

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

StatefulSericeTest.java

class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
       ...
        //ThreadA : A 사용자 10000원 주문
        int userAPrice = statefulService1.order("userA", 10000);
        //ThreadB : B 사용자 20000원 주문
        int userBPrice = statefulService2.order("userB", 20000);

        //ThreadA : 사용자 A 주문 금액 조회
        System.out.println("price = " + userAPrice);
    }
    ...
}

상태를 공유하는 변수인 price를 없애고 order 메서드의 반환값으로 price를 리턴하며 사용자 각각의 주문 금액을 정확하게 조회할 수 있게 되었다.

 

+ @Configuration과 싱글톤

@Configuration과 싱글톤
AppConfig를 보면 memberService, orderService 빈을 만들때 동일하게 new MemoryMemberRepository를 수행함
-> 2개의 다른 객체가 생성되며 싱글톤이 깨지는 것인가?
-> 테스트 코드로 객체 비교 결과, 동일한 참조 값을 가진다는 걸 알 수 있다. 같은 인스턴스가 공유되고 있는 것!
-> 두번 new하는데 어떻게 이게 가능? 두 번 호출이 안되는거 아님?
-> ㅇㅇ new MemoryMemberRepository는 한 번만 수행됨
-> 이게 가능한 이유는?

@Configuration과 바이트코드 조작
AppConfig.java의 @Configuration이 이를 가능케 해준다.
AppConfig의 빈을 조회하여 클래스 정보를 보면 class hello.core.AppConfig가 아닌 xxxCGLIB가 붙은 클래스가 조회된다
- 이는 내가 만든 AppConfig와는 다름
- 스프링이 GBLIB라는 바이트 조작 라이브러리를 사용해서 AppConfig클래스를 상속받은 임의의 클래스를 만든 것! 그리고 AppConfig가 아닌 바이트 조작된 AppConfig 클래스가 스프링 빈으로 등록됐다
- 이 임의의 클래스가 싱글톤을 보장해줌 : Bean이 붙은 메서드에 스프링 빈이 이미 존재하면 존재하는 빈을 찾아 반환 / 스프링 빈이 없다면 생성, 스프링 빈으로 등록 후 반환

AppConfig@CGLIB 예상 클래스 내부 구조

@Bean
public MemberRepository memberRepository() {
    if (memoryMemberRepository in 스프링 컨테이너) 
        return 스프링 컨테이너에서 인스턴스 찾아서 반환
    else
        기존 로직(new)을 호출해서 MemoryMemberRepository 생성 & 스프링 컨테이너에 등록
        return 인스턴스 반환
}

@Configuration을 적용하지 않고 @Bean만 적용한다면?
스프링 빈은 생성되지만 싱글톤은 보장 안 됨
이때, AppConfig 메서드의 new연산은 구체 클래스를 할당한 것과 동일한 결과를 냄(MemberRepository memberRepository = new MemoryMemberRepository() - DIP, OCP 위반!)

⇒  스프링 설정 정보는 항상 @Configuration을 사용할 것!