Spring 핵심 원리 - 싱글톤

박양원·2024년 2월 20일

Singleton Spring

Spring Basic

목록 보기

3/4

싱글톤

싱글톤 패턴

클래스의 인스턴스가 오직 1개만 생성되는 것을 보장하는 디자인 패턴
private 생성자를 이용하여 외부에서 임의로 new 키워드를 사용하지 못하게 해야 함

public class SingletonService {
    
    // static 영역에 객체를 하나만 생성
    private static final SingletonService instance = new SingletonService();
    
    // 이 객체의 인스턴스가 필요하면 아래의 static 메소드를 통해서만 조회 가능
    public static SingletonService getInstance() {
        return instance;
    }
    
    // private으로 생성자 만듬 => 외부에서 생성 불가!!
    private SingletonService() {
        
    }
    
    public void logic() {
        System.out.println("싱글톤 객체 호출");
    }
}

getInstance() 메소드를 통해서만 조회 가능하므로 항상 같은 인스턴스를 반환해줌

싱글톤 패턴의 문제점

아래의 이유들로 인하여 유연성이 떨어져 안티 패턴으로 불리기도 함

구현 코드가 많이 필요
클라이언트가 구체 클래스에 의존함 (구현체.getInstacne 사용 -> DIP 위반)
OCP 또한 위반할 가능성이 높음
테스트가 어려움
내부 속성을 변경 또는 초기화 하기 어려움
private 생성자로 자식 클래스를 만들기 어려움

스프링 컨테이너로 해결

스프링 컨테이너는 싱글톤 컨테이너 역할을 함
위에서 언급한 모든 문제점을 해결하고 싱글톤으로 객체(스프링 빈)를 관리해줌
싱글톤 레지스트리
- 싱글톤 객체를 생성하고 관리하는 기능

싱글톤 방식의 주의점!!!

스프링 컨테이너를 쓰든 말든 싱글톤 패턴은 객체 인스턴스를 하나만 생성하여 공유함
따라서 객체의 상태를 절대 유지하게 설계해선 안되고 항상 무상태(stateless)로 설계해야 함
무상태 설계
- 특정 클라이언트에 의존적인 필드가 없어야 함
- 특정 클라이언트가 값을 변경할 수 있는 필드를 가져선 안됨
- 가급적이면 읽기만 가능 (수정 X)
- 필드가 아닌 지역변수, 파라미터, ThreadLocal 등을 사용해야 함

예시

public class StatefulService {

    private int price;

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

    public int getPrice() {
        return price;
    }
}

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

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

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

        // 기대한 값은 1만원 But 실제 값은 2만원이 나옴
        //  => 스프링 컨테이너는 하나의 인스턴스를 공유하는 싱글톤 패턴임
        //  => servic1, servic2 모두 하나의 인스턴스이므로 뒤에 넣은 2만원으로 덮어씌워짐
        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }
        static class TestConfig {

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

}

위의 경우 공유되는 price필드를 특정 클라이언트가 값을 변경할 수 있게 설계되어 있음
따라서 userA의 주문 금액을 1만원으로 기대하였으나 실제로 2만원이 조회됨

수정

Service의 order 메소드가 price값을 반환하게 만듬
반환된 값을 지역변수로 생성하여 값을 담아주면 별도의 변수가 2개 생성되므로 위의 문제를 해결할 수 있음

public class StatefulService {

    private int price;

    // int를 반환하게 만듬
    public int order(String name, int price) {
        System.out.println("name = " + name);
        System.out.println("price = " + price);
        this.price = price; // 여기가 문제!!!

        return price; // 아예 price값을 반환해주면 문제 해결!!!
    }
}

Spring에서 Appconfig의 싱글톤 보장

@Test
void configurationDeep() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    AppConfig bean = ac.getBean(AppConfig.class);

    // CGLIB으로 나옴
    // 바이트코드 조작 라이브러리를 사용하여 AppConfig 클래스를 상속받은 임의의 클래스를 생성
    // 위의 클래스를 스프링 빈에 등록해줌 => 이 친구가 싱글톤을 보장해줌
    System.out.println("bean = " + bean.getClass());
}

// bean = class com.example.basicreview.AppConfig$$EnhancerBySpringCGLIB$$8743a0