[Spring] 싱글톤 컨테이너

싱글톤 컨테이너

---

# 웹 애플리케이션과 싱글톤

- 스프링은 기업용 온라인 서비스 기술을 지원하기 위해 탄생함.

- 대부분의 스프링 애플리케이션은 웹 애플리케이션이며, 웹 애플리케이션은 보통 여러 고객들이 동시에 요청을 함.

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public OrderService orderService(){
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

  위와 같이 DI 컨테이너를 작성하였을 때, 3 명의 클라이언트가 memberService 를 요청하는 상황을 가정해보자. 요청이 들어오면 DI 컨테이너(AppConfig)는 각각 다른 memberService 객체를 반환한다. 웹 어플리케이션은 고객의 요청이 계속 발생하는데, 요청이 발생할 때 마다 계속 새로운 객체를 만들어야 한다. (문제점)

 

package hello.core.singleton;
import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class SingletonTest {
    @Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너")
    void pureContainer(){
        AppConfig appConfig = new AppConfig();
        // 1. 조회 : 호출할 때 마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();
        MemberService memberService2 = appConfig.memberService();

        // 참조값이 다른 것을 확인해보자
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        Assertions.assertThat(memberService1).isNotSameAs(memberService2);
    }
}

 위 테스트 코드를 실행 시, 아래와 같이 각각의 MemberService 객체는 참조값이 다른 것을 확인할 수 있다.

memberService1 = hello.core.member.MemberServiceImpl@ba2f4ec
memberService2 = hello.core.member.MemberServiceImpl@1c1bbc4e

조회 요청이 들어올 때 마다 새로운 객체를 만들어주어야 하므로 이것이 JVM 메모리에 쌓이는 구조이다. (비효율적) 규모가 커지면 더욱 안좋은 결과가 발생할 수 있을 것! 고객 트래픽이 초당 100 이라고 가정하면, 초당 100 개의 객체가 생성되고 소멸될 것이다.(메모리 낭비)

  >>  해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 해결이 가능하며 이를 싱글톤 패턴(singleton pattern) 이라고 한다.

 

# 싱글톤 패턴 (Singleton Pattern)

- 싱글톤 패턴이란 클래스의 인스턴스가 딱 한 개만 생성되는 것을 보장하는 디자인 패턴이다.

- 이를 위해서는 객체 인스턴스를 2개 이상 생성되지 못하도록 막아야 한다.

  >>  private 생성자를 사용하여 외부에서 임의로 new 키워드를 이용하지 못하도록 막으면 된다.

  >> 아래 예제 코드를 보자.

package hello.core.singleton;

public class SingletonService {
    private static final SingletonService instance = new SingletonService();
    // static 으로 선언함으로써 클래스 level 에 존재하므로 단 한 개만 존재함.

    // 1. static 영역에 객체를 딱 1개만 생성해둔다.
    public static SingletonService getInstance(){
        return instance;
    }
    // 2. public 으로 열어서 객체 인스턴스가 필요하다면 이 static 메서드를 통해서만 조회하도록 허용.
    private SingletonService(){
    }
    // 3. 생성자를 private 으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막음.
    public void logic(){
        System.out.println("싱글톤 객체 logic 호출");
    }
}

-  위와 같이 static 영역에 객체 instance 를 미리 하나 생성해두어서 올려둔다.

-  해당 객체가 필요하면 getInstance() 메서드로만 조회가 가능하다. 이로부터 항상 같은 인스턴스를 반환받을 수 있다.

-  오직 1 개의 객체 인스턴스만 존재해야 하므로, 생성자를 private 으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 방지한다.

 

>> 아래 테스트 코드를 보자

@Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용")
    void singletonServiceTest(){
        SingletonService singletonService1 = SingletonService.getInstance();
        SingletonService singletonService2 = SingletonService.getInstance();

        System.out.println("singletonService1 = " + singletonService1);
        System.out.println("singletonService2 = " + singletonService2);

        Assertions.assertThat(singletonService1).isSameAs(singletonService2);
    }

singletonService1 = hello.core.singleton.SingletonService@2cd76f31
singletonService2 = hello.core.singleton.SingletonService@2cd76f31

Process finished with exit code 0

-  위와 같이 Singleton pattern 을 사용한 객체를 여러 번 호출하여도 항상 같은 객체가 방지된다는 것을 확인할 수 있다.

-  Spring 컨테이너를 사용하면, 기본적으로 객체를 singleton 으로 만들어서 관리해준다!

-  싱글톤 패턴을 적용하면 이미 만들어진 객체를 공유해서 효율적으로 사용이 가능하지만 아래의 문제점이 존재한다.

 

<싱글톤 패턴의 문제점>

-  싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.

-  의존관계 상 클라이언트가 구체 클래스에 의존하게 되어, DIP 를 위반.

- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 생긴다.

- 테스트 하기가 어렵다.

- 내부 속성을 변경/초기화 하기에 까다롭다.

- private 생성자로 자식 클래스를 만들기 어렵다.

- 유연성이 떨어져서, 안티 패턴이라고 불리기도 한다.

 

>> 스프링 컨테이너느 위와 같은 싱글톤 패턴을 전부 해결하면서도 객체를 싱글톤으로 관리한다.

 

# 싱글톤 컨테이너

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

- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리해준다. 컨테이너는 객체 하나만 생성해서 관리한다. 스프링 컨테이너는 싱글톤 컨테이너 역할을 하며, 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다. 이러한 기능 덕분에 싱글톤 패턴의 단점을 해결하며, 객체를 싱글톤으로 유지할 수 있게 해준다.

- 싱글톤 패턴을 위한 부가적인 코드가 필요하지 않으며 DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다. 

 

>> 아래의 테스트 코드를 보자

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

        // 참조값이 같은 것을 확인해보자
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        Assertions.assertThat(memberService1).isSameAs(memberService2);
    }

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

 

 * 스프링의 기본 빈 등록 방식은 싱글톤이기는 하나 다양한 방식을 제공한다. 요청이 들어올 때 마다 새로운 객체를 생성해서 반환하는 기능 또한 제공하며, 이는 이후에 빈 스코프에서 공부하도록 하자!

 

# 🧐 싱글톤 방식의 주의점

- 싱글톤 패턴을 적용하든 싱글톤 컨테이너를 사용하든 어찌되었든 간에 객체 인스턴스를 하나만 생성하는 방식이 바로 싱글톤 패턴이다. 이러한 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. stateless 하도록 설계해야 하는데, 이를 위해서 아래 조건을 만족해야 한다.

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

(2) 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.

(3) 가급적이면 읽기만 가능해야 한다.

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

 

😒스프링 빈의 필드에 공유값을 설정하면 큰 장애가 발생할 수 있다. 아래 예시를 보자!

package hello.core.singleton;

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

위와 같이 StatefulService 클래스를 선언하고 아래와 같이 테스트 코드를 만들었다.

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;


class StatefulServiceTest {
    @Test
    void statefulServiceTest(){
        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);

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

}

위 테스트 코드의 상황은 단순하다. 사용자 A 가 10000 원을 주문하고 이어서 바로 사용자 B 가 20000 원을 주문하였다. 그리고 나서 statefulService1.getPrice() 를 꺼내서 사용자 A 가 주문한 금액을 확인해보면 10000 원이 아니라 20000 이 된 것을 확인할 수 있다... 이러한 경우를 방지하기 위해서 반드시 스프링 빈은 무상태(stateless)로 설계해야 한다!

예를 들어서 아래와 같이 설계하면 된다.

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

 

 

# @Configuration 과 싱글톤

스프링 컨테이너는 싱글톤 레지스트리이므로 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 하지만 스프링이 자바 코드를 일일이 제어하기는 어려운데, 이를 극복하기 위해 클래스의 바이트코드를 조작하는 라이브러리인 CGLIB 를 사용한다. AppConfig 클래스를 상속받은 임의의 다른 클래스를 만든 다음에 해당 클래스를 스프링 빈으로 등록한다. 이 임의의 다른 클래스가 싱글톤을 보장해주도록 해주는 것이다. 대략 아래의 원리로 작성되었을 것이다.

@Bean
public MemberRepository memberRepository(){
	if(memoryMemberRepository 가 스프링 컨테이너에 이미 등록되어 있다면){
    		return 스프링 컨테이너에서 이를 찾아서 반환;
       }
    else { // 스프링 컨테이너에 없다면
    	기존 로직을 호출하여 MemoryMemberRepository 를 생성한 다음에 스프링 컨테이너에 등록
        return 반환
    }
 }

- @Bean 이 붙어있는 메서드마다 이미 스프링 빈이 컨테이너에 존재하면, 존재하는 빈을 컨테이너에서 찾아서 반환하고, 스프링 빈이 컨테이너에 없다면 생성해서 스프링 빈을 등록하고 반환하는 코드가 동적으로 만들어 지는 것이며 이 덕분에 싱글톤이 보장되는 것이다.

 

- 정리하자면 @Bean 만 사용해도 스프링 빈으로 등록되지만 싱글톤이 보장되지 않는다. 스프링 설정 정보는 항상 @Configuration 을 사용하면 만사해결!

---

 

Reference

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

스프링 핵심 원리 - 기본편 - 인프런 | 강의