[스프링 핵심 원리] 05. 싱글톤 컨테이너 - 싱글톤 컨테이너 & 싱글톤 방식의 주의점(중요★)

(인프런) 김영한님의 스프링 핵심 원리-기본편을 공부하고 리뷰한 글입니다.

3. 싱글톤 컨테이너

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

지금까지 우리가 학습한 스프링 빈은 싱글톤으로 관리되는 빈이다.

 

1. 싱글톤 컨테이너

- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.

- 스프링 컨테이너는 싱글톤 컨테이너 역할을 하고 싱글톤 객체를 생성, 관리하는 기능을 싱글톤 레지스트리라고 한다.

- 스프링 컨테이너는 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

• 싱글톤 패턴을 위한 지저분한 코드X
• DIP, OCP, 테스트, private 생성자로부터 자유롭게 자유롭게 싱글톤 사용O

2. 스프링 컨테이너를 사용하는 테스트 코드

1) 코드 작성

package hello.core.singleton;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import static org.assertj.core.api.Assertions.*;

public class SingletonTest {
	...

    @Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void springContainer() {
        // 스프링 컨테이너 생성
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        // 1. 조회: 호출할 때 마다 같은 객체를 반환
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        // 2. 조회: 호출할 때 마다 같은 객체를 반환
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);

        // 위에서 반환된 객체 2개의 참조값이 값은지 확인
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        // memberService1 == memberService2 (두 객체가 값은지) 검증
        assertThat(memberService1).isSameAs(memberService2);
    }
}

 

2) 결과

 

3. 싱글톤 컨테이너 적용 후

스프링 컨테이너 덕분에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다. 이것이 바로 스프링 컨테이너를 사용하는 이유다. (이전에 이에 대한 의문점을 가졌었던 글은 여기서)

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

4. 싱글톤 방식의 주의점(너무 중요!!)

객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유한다. 그러므로 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안되고 무상태(stateless)로 설계해야 한다!! 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!

 

<무상태(stateless) 설계 방법>

- 특정 클라이언트에 의존적인 필드가 있으면 안된다.

- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다! 

- 가급적 읽기만 가능해야 한다.

- 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

 

1. 상태를 유지할 경우 발생하는 문제점 예시

1) StatefulService 코드 작성

상태를 유지하는 필드(price)가 있다. 클라이언트가 order()를 호출하면 넘어온 파라미터 price 값이 필드 값(price)를 변경하는 문제가 생긴다.

package hello.core.singleton;

public class StatefulService {
    private int price;  // 상태를 유지하는 필드 (10000 -> 20000)

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

    public int getPrice() {
        return price;
    }
}

 

2) StatefulServiceTest 코드 작성

단순한 설명을 위해 실제 쓰레드는 사용하지 않았고 ThreadA가 사용자 A 코드를 호출하고, ThreadB가 사용자 B 코드를 호출한다고 가정한다.

StatefulService의 price 필드는 공유되는 필드인데, 위 코드에서 특정 클라이언트가 값을 변경하고 있다.

package hello.core.singleton;

import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;

import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

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);     // 20000원 출력(중간에 사용자B가 price를 바꾸었기 때문)
        
        // A사용자 주문 금액이 20000원인지 검증
        assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

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

}

 

3) 결과

실제로 A사용자의 주문 금액은 10000원이지만 20000원이라는 결과가 나왔다.

사용자 A가 주문을 하고 금액을 조회하기 전에 사용자 B가 주문을 하면서 필드값(price)가 변경되었기 때문이다. 이러한 공유 필드 문제는 실무에서 종종 발생하는데 정말 해결하기 어려운 큰 문제들이므로 주의하자.

 

2. 문제점 해결(공유 필드 -> 지역 변수 사용)

원래는 price를 공유필드로 사용했지만, order() 메서드 내에서 지역변수 price를 그대로 리턴하는 방식으로 변경한다.

1) StatefulService 코드 수정

price 공유 필드를 사용하지 않고 order() 내에서 price 지역변수를 리턴한다. getPrice()는 삭제한다.

package hello.core.singleton;

public class StatefulService {

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

 

2) StatefulServiceTest 코드 수정

package hello.core.singleton;

import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;

import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

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

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

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

}

 

3) 결과

A 사용자의 주문 금액이 10000원이 제대로 나오는 것을 확인 할 수 있다.

---

<정리>

1. 스프링은 기본적으로 싱글톤 방식으로 동작한다.

2. 싱글톤 객체(스프링 빈)은 항상 무상태로 설계해야 한다. (완전 중요!!)
3. 공유 필드 조심하자!!