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

싱글톤

기존 스프링 없는 순수한 DI 컨테이너인 AppConfig 는 요청을 할 때 마다 객체를 새로 생성한다. 예를들어 고객 트래픽이 초당 100이라면 초당 100개 객체가 생성되고 소멸된다 → 메모리낭비

따라서 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다 → 싱글톤 패턴

 

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
• 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야한다.
  •  private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 해야함

public class SingletonService {

    // 1. static 영역에 객체 1개만 생성
    private static final SingletonService instance = new SingletonService();

    // 2. public으로 열어서 객체가 필요하면 이 static `getInstance()` 메서드를 통해서만 조회하도록 허용
    public static SingletonService getInstance() {
        return instance;
    }

    
    private SingletonService() {
        // 3. private 생성자 선언하여 외부에서 new 객체 생성 방지
    }

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

    }
}

싱글톤 패턴 적용 X                                                                            싱글톤 패턴 적용O → 같은 객체를 사용한 것을 볼 수 있다.                                                                                                                         

 

싱글톤 패턴 단점

• 싱글톤 패턴을 구현하는 코드 자체가 많이들어감
• 의존관계상 클라이언트가 구체 클래스에 의존 → DIP 위반 + OCP 위반 가능성높다.
• 등등의 단점을 해결하기위해 → 싱글톤 컨테이너 적용

 

싱글톤 컨테이너

사실 스프링 빈이 바로 싱글톤으로 관리되는 빈이다.

• 스프링 컨테이너는 싱글 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 보장한다!!

참고로 스프링의 기본 빈 등록 방식은 싱글톤이지만 싱글톤 방식만 지원하는 것은 아니다. 요청할 때 마다 새로운 객체를 생성하여 반환하는 기능도 제공한다.

 

 

싱글톤 방식의 주의점

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

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

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);
        statefulService2.order("userB", 20000);

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

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

 

•  StatefulService 의  price 필드는 공유되는 필드인데 특정 클라이언트가 값을 변경한다.
• A사용자 주문금액은 10000원이 되어야하는데 20000원이라는 결과가 나올 수 있다.
• 공유필드는 항상 조심해야한다!! 스프링 빈은 항상 무상태(stateless)로 설계하자

 

@Configuration

스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 하는데 스프링이 자바 코드까지는 어떻게 하기 어렵다. 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.  @Configuration  을 적용한  AppConfig  에 비밀이 있다.

 

@Test
void configurationDeep() {

 	ApplicationContext ac = new
	AnnotationConfigApplicationContext(AppConfig.class);

	//AppConfig도 스프링 빈으로 등록된다.
	AppConfig bean = ac.getBean(AppConfig.class);

	System.out.println("bean = " + bean.getClass());
}
// 출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

 

순수 클래스라면 → class hello.core.AppConfig가 출력 되어야 하지만 예상과 다르게 복잡해졌다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용하여 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것! 따라서 그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다!

 

정리

•  @Bean 만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지는 않는다.
  • 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.
• 따라서 스프링 설정 정보는 항상  @Configuration 을 사용하여 싱글톤을 보장하자