[스프링 핵심원리] - 4.싱글톤 컨테이너 (2)

Chooooo·2022년 11월 4일
0
post-thumbnail

이 글은 강의 : 김영한님의 - "스프링 핵심원리 - 기본편"을 듣고 정리한 내용입니다. 😁😁


싱글톤 컨테이너 & 싱글톤 방식의 주의점에 대해 알아볼 것이다. (매우 중요)

싱글톤 컨테이너

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

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

싱글톤 컨테이너

  • 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.
    - 스프링 컨테이너싱글톤 컨테이너 역할을 하고 싱글톤 객체를 생성, 관리하는 기능을 싱글톤 레지스트리라고 한다.

  • 스프링 컨테이너싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
    - 싱글톤 패턴을 위한 지저분한 코드 필요없어짐!

    • DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤 사용 O

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

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

두 객체가 같다는 결과가 나온다!

싱글톤 컨테이너 적용 후

스프링 컨테이너 덕분에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다. 이것이 바로 스프링 컨테이너를 사용하는 이유다.

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

싱글톤 방식의 주의점

이 부분은 너무 중요!!

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

무상태(stateless) 설계 방법

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

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

  • 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;
    }
}
  • 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();
        }
    }

}

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

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

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

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

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

package hello.core.singleton;

public class StatefulService {

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

StatefulServiceTest 실행하면 제대로 나온다!

정리하자면

  • 스프링은 기본적으로 싱글톤 방식으로 동작한다.
  • 싱글톤 객체(스프링 빈)은 항상 무상태로 설계해야 한다.(매우 중요!)
profile
back-end, 지속 성장 가능한 개발자를 향하여

0개의 댓글