스프링 핵심 원리 - 싱글톤 컨테이너, @Configuration

싱글톤 패턴

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

package hello.core.singleton;

public class SingletonService {
    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    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("싱글톤 객체 로직 호출");
    }
}

싱글톤 패턴의 단점

싱글톤 패턴을 규현하는 코드 자체가 많이 들어간다.
의존 관계상 클라이언트가 구체 클래스에 의존한다. → DIP 위반
클라이언트가 구체 클래스에 의존해서 OCP 위한할 가능성 높음
private 생성자로 자식 클래스를 만들기 어려움
유연성이 떨어져서 안티패턴으로 불리기도 함

싱글톤 컨테이너

스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리해준다.
싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
싱글톤 레지스트리 덕분에 싱글턴 패턴의 단점을 해결하면서 객체를 싱글톤으로 유지가 가능하다.
DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

싱글톤 방식의 주의점

싱글톤 방식은 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계 하면 안된다.
무상태로 설계 해야한다.

package hello.core.singleton;

public class StatefulService {

    private int price; //상태를 유지하는 필드

    public int order(String name, int price){
        System.out.println("name = " + name + "price = "+price);/        this.price = price; //여기가 문제!
        this.price = price; **//여기가 문제!! -> 상태를 유지하게 설계됨**
    }

    public int getPrice() {
        return price;
    }
}

StatefulService의 price필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.

package hello.core.singleton;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;

public class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
        AnnotationConfigApplicationContext 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);

        //ThreadA: 사용자A 주문 금액 조회
        int price = statefulService1.getPrice();
        //ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
        System.out.println("price = " + price);

        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }
    static class TestConfig{
        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }
}

사용자 A가 10000원을 주문하고, 조회하기전에 사용자 B가 20000원을 주문하면, this.price = price; 때문에 A가 주문을 조회 했을때, 10000원이 아닌 20000원이 나온다. → price필드를 공유하는 설계 때문!
스프링 빈은 항상 무상태(stateless)로 설계 해야 한다!

@Configuration과 바이트 코드 조작

@Configutration : 설정파일을 만들기 위한 애노테이션 or Bean을 등록하기 위한 애노테이션이다.
@Configuration을 적용한 AppConfig 는 바이트 코드를 조작한 CGLIB라는 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 클래스를 만들고 그것을 스프링 빈으로 등록 해준다.

@Configuration 을 사용하지 않고, @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤은 보장 되지 않는다.
스프링 설정 정보에 @Configuration 을 사용하면 싱글톤을 보장받을 수 있다.