[Spring] 싱글톤 컨테이너 개념 정리

728x90

웹 애플리케이션과 싱글톤

사실 애플리케이션은 굉장히 종류가 많다.

온라인에 대한 처리뿐만 아니라 서버의 백그라운드 데몬 같은 프로세스와 더불어 하나의 단위로 묶어 배치로 처리해주는 등 다양한 종류의 애플리케이션이 존재한다.

그중에서도 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다.
대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 가능하다.
웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.

스프링이 없는 순수 DI 컨테이너로 구현할시 고객이 요청할 때 마다 새로운 객체가 생성된다.

이렇게 되면, 고객의 요청이 들어올 때마다 뭔가를 계속해서 만들어내게 된다. -> 이것이 문제가 된다.

진짜 고객 요청 시마다 객체를 만드는지 테스트해 보자.

실제로 테스트 코드 작성해서 실행하면 매번 새로운 객체가 생성됨 -> 사실 당연한 결과지

위와 같이 매번 새로운 객체가 생성됨을 확인할 수 있다.

이는 고객의 요청이 참 많은 웹 애플리케이션의 특징을 생각했을 때, 좋은 방식이 아니다.

이전에 만들었던 스프링이 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성한다.
고객 트래픽이 초당 100이 나온다 치면, 초당 100개의 객체가 생성되고 소멸한다! -> 메모리 낭비가 극심하다.
해결 방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다!! -> 이것이 싱글톤 패턴

싱글톤 패턴

싱글톤 패턴은 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다!!
그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다!!
- private 생성자를 사용해 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.

코드로 알아보자.

package hello.core.singleton;

public class SingletonService {

    // 자기 자신을 클래스 내에 딱 하나만 갖도록 설계한다. (private로, 또한 class level로 올라가므로 당연히 한 개밖에 존재하지 못한다.)
    private static final SingletonService instance = new SingletonService();
    // final: 제한한다는 의미로 변수에 붙이는 경우 수정할 수 없음을 의미, 따라서 변수로 사용하는 경우 초기화가 필수이다.
    // method에 붙이면, override 금지를 class에 붙으면 상속 금지를 의미한다.

    // getInstance method 를 통해서만, 객체를 반환받도록 설계한다.
    public static SingletonService getInstance(){
        return instance;
    }

    private SingletonService(){
        // 이렇게 private 생성자를 따로 만들어, 중복된 객체의 선언을 막는다.
    }

    public void logic(){
        System.out.println("싱글톤 객체의 로직을 호출");
    }
}

코드 설명

static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
이 객체 instance가 필요하면, 오직 getInstance() method를 통해서만 조회할 수 있다. 메서드 호출 시 항상 같은 instance를 반환한다.
딱 1개의 객체 instance만 존재해야 하므로, 생성자를 private로 막아 혹시라도 외부에서 new 키워드로 객체 instance를 생성하는 것을 막아준다.

isSameAs와 isEqualTo 차이점

isSameAs: "=="와 같다. instance가 같은지 여부를 판단
isEqualTo: java의 equlas method와 같음. 객체에 담긴 값을 비교하는 듯

위와 같은 방식은 싱글톤 패턴을 구현하는 가장 단순하고 안전한 방법이라고 한다. 다른 방법도 많기 때문에 나중에 참고해 보자.

이렇게 싱글톤 패턴으로 구현을 하는 경우 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라 하나의 객체를 공유해서 사용할 수 있다는 장점이 있지만, 다음과 같은 수많은 문제점들을 갖고 있다.

싱글톤 패턴의 문제점 정리

싱글톤 패턴을 구현하기 위해 코드 자체가 많이 들어간다.
의존관계상 클라이언트가 구체 클래스에 의존하게 된다. -> DIP 위반
같은 이유로 OCP를 위반할 가능성 또한 높아진다.
테스트 또한 어렵다
내부 속성을 변경하거나 초기화하기 어렵다.
private 생성자를 사용하기 때문에, 자식 클래스를 만들기가 어렵다.
결론적으로 유연성이 떨어짐
안티패턴으로 불리기도 한다.

하지만, 이러한 문제들을 스프링을 이용하면 단점들은 해결하고 장점들은 잘 뽑아서 사용할 수 있다고 한다. 이어서 정리해 보자.

싱글톤 컨테이너

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

지금까지 우리가 배운 스프링 빈이 바로 싱글톤으로 관리되는 빈이라고 할 수 있다.

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴을 따로 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리해 준다.
- 이전에 설명한 컨테이너 생성 과정을 다시 떠올려보면, 컨테이너는 하나의 객체만을 생성해서 관리했다는 것을 떠올릴 수 있다.
스프링 컨테이너는 싱글톤 컨테이너의 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점들은 해소되고, 객체를 싱글톤으로 유지할 수 있게 된다.
- 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
- DIP, OCP, 테스트, private 생서자로부터 자유롭게 싱글톤을 사용할 수 있다.

실제로 따로 싱글톤 패턴을 위한 코드 작성 없이 스프링 컨테이너에 등록된 같은 유형의 빈 두 개를 비교해 보자.

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    MemberService memberService1 = ac.getBean("memberService", MemberService.class);
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);
    
    System.out.println("memberService1 = " + memberService1);
    System.out.println("memberService2 = " + memberService2);
    
    //두 개의 스프링 빈이 같은지 확인한다.
    assertThat(memberService1).isSameAs(memberService2);
}

이렇게 스프링 컨테이너를 사용하면, 매번 새로운 객체를 만들지 않고, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.

참고: 스프링 컨테이너는 기본적으로 싱글톤 패턴을 지원하지만, 싱글톤 방식만 지원하는 것은 아니다. 자세한 내용은 빈 스코프 챕터에서 공부하자.

싱글톤 방식의 주의할 점

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 하나의 객체를 생성해 여러 클라이언트가 공유하는 싱글톤 방식은 싱글톤 객체를 stateless 하게 설계해야 한다!! (not stateful)
따라서 무상태(stateless)로 설계해야 한다!
- 특정 클라이언트에 의존적인 필드가 있으면 안 됨
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 됨
- 가급적 읽기만 가능해야
- 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, 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 this.price;
    }
}

위와 같이 StatefulService라는 class가 정의되어 있고, 이를 다음과 같은 코드를 이용해 테스트한다고 해보자.

@Test
void statefulServiceSingleton(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
    StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
    StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);

    //Thread A: A 사용자가 10000원 주문
    statefulService1.order("userA", 10000);
    //Thread B: B 사용자가 20000원 주문
    statefulService2.order("userB", 20000);

    //Thread A: 사용자 A 주문 금액 조회
    int price = statefulService1.getPrice();
    System.out.println("price = " + price); // 20000원으로 나온다.

    assertThat(statefulService1.getPrice()).isEqualTo(10000);
}

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

이렇게 되는 경우에는 앞에서 정리한 싱글톤 방식을 도입할 시에는 무상태로 설계해야 한다는 점을 위배하게 된다.

특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 됨! (private int price)
가급적 읽기만 가능해야 (order에서 write)
같은 문제들이 발생한다.

그래서 테스트 결과 다음과 같이 사용자 A의 결제 금액이 10,000원이 아닌 20,000원으로 나오는 실패가 뜬다.

이런 경우 다음과 같이 로컬 영역에 price 값을 넣어 각각의 클라이언트가 공유되는 값을 수정할 수 없도록 설계해야 한다.

price를 공유하는 필드가 아니라, 로컬 영역 안에 넣어버리고 주문시 바로 반환하도록 설계를 변경

앞의 설명은 최대한 단순하게 하기 위해 실제 쓰레드를 사용한 경우가 아니라고 한다.
ThreadA가 사용자 A 코드를 호출하고, ThreadB가 사용자 B 코드를 호출한다고 가정하자.
StatefulService의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경하는 상황이 발생한다.
사용자 A의 주문 금액은 10,000원이 되어야 하는데, 20,000원으로 출력되는 문제가 발생
실무에서 이런 경우가 종종 나오는데, 이로 인해 정말 해결하기 어려운 큰 문제들이 터진다고 한다.. (몇 년에 한 번씩은 꼭 터진다고)
진짜 공유 필드는 조심해야 한다!! 스프링 빈은 항상 무상태(stateless)로 설계하자.

@Configuration과 싱글톤

이번에는 @Configuration annotation의 비밀에 대해서 하나씩 파해쳐보자. 이게 사실은 singleton을 위해 존재하는 거라고 한다.

AppConfig의 예시 코드를 한 번 살펴보자. 여기에 뭔가 이상한 점이 있다.

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

이런 코드에서 이렇게 동작하지 않을까??

memberService bean을 만드는 코드에서 memberRepository()를 호출
- 메서드 호출 시에 new MemoryMemberRepository()를 호출한다.
orderService bean을 만드는 코드에서도 memberRepository()를 호출
- 메서드 호출 시에 new MemoryMemberRepository()를 또 호출한다.

결과적으로 그냥 자바 코드를 호출하는 것이기 때문에, 각각 다른 2개의 MemoryMemberRepository가 생성되며, 싱글톤이 깨지는 것처럼 보인다.

스프링 컨테이너를 사용하면, 이런 문제를 해결해준다고 하는데 어떻게?? (분명히 싱글톤 방식을 보장해준다고 함)

테스트 용도로 각각의 구현체에 위와 같이 memberRepository를 반환하는 코드를 추가한 다음에 아래의 테스트 코드를 돌려본다.

신기하게도 위와 같이 테스트는 통과한다. (isSameAs를 이용한 테스트)

결과를 보면 알 수 있듯이, 세 개가 전부 같은 것을 확인할 수 있다.

세 번의 new MemoryMemberRepository()가 생성되는 것이 맞는데, 왜 그렇게 되지 않을까??

실험해 보자.

AppConfig에 가서 이렇게 soutm을 이용해 문자열을 출력하도록 세팅해보자.

어떻게 AppConfig가 실행되고, 스프링 빈이 등록되는 구조인지 알아보기 위해 직접 찍어서 확인하는 방식을 채택한다.

다음과 같이 출력될 것으로 예상할 수 있을 것 같다.

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository

그러나 테스트 코드를 실행한 결과 다음과 같이 찍힌다.

의도와 다르게 이상하게도 한 번의 memberRepository method만 호출된다...

여기서 스프링이 어떠한 방법을 취해서든 싱글톤을 보장해주는 것을 확인할 수 있다. 자바 코드로는 설명이 잘 안 됨

@Configuration과 바이트코드 조작의 마법

스프링 컨테이너는 싱글톤 레지스트리이다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다.

앞서 살펴보았듯이, AppConfig 코드를 보면 분명히 memberRepository method가 3번 호출되어야 하는 것이 맞는데, 그렇지 않은 결과를 확인할 수 있다.

이것은 스프링이 클래스의 바이트 코드를 조작하는 라이브러리를 사용하기 때문인데, 이 비밀은 모두 @Configuration을 적용한 AppConfig에 있다.

이번에는 이런 테스트 코드를 활용해서 AppConfig의 bean을 출력해보자.

위 테스트 코드를 실행하면, 뭔가 이상한 결과를 얻게 된다.

위와 같이 AppConfig 스프링 빈을 조회해서 클래스 정보를 출력한 결과, EnhancerBySpringCGLIB라는 것이 추가적으로 붙는 결과를 확인 가능

이게 뭘까??

class hello.core.AppConfig

원래는 위와 같이 출력되었어야

그런데, 예상과 다르게 클래스 명에 xxxCGLIB가 붙으며 상당히 복잡해진 것을 볼 수 있다. 이것은 바로 내가 만든 클래스가 아닌 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스의 객체가 스프링 빈으로 등록되었음을 의미한다!!

이렇게 임의로 만들어진 다른 클래스가 바로 싱글톤이 되도록 보장해 준다. 아마 다음과 같이 바이트 코드를 조작해 작성되어 있을 것.. (실제로는 CGLIB의 내부 기술을 사용하는데 매우 복잡하다고 한다..)

@Bean 어노테이션이 붙은 메서드마다 스프링 컨테이너에 빈이 등록되어있는지를 확인하고 없으면 새로 생성하는 구조의 코드가 동적으로 만들어진다.
이러한 구조 덕분에 싱글톤 패턴이 보장된다.

참고: AppConfig@CGLIB는 AppConfig의 자식 타입이므로, AppConfig 타입으로 스프링 빈 조회가 가능했던 것이다.

@Configuration을 적용하는 이유가 뭘까?

이것을 확인하기 위해 @Configuration annotation을 빼고 스프링 컨테이너를 생성해 보자.

@Configuration 어노테이션을 작성하지 않고, 테스트 코드를 실행해서 memberRepository를 확인한 결과 처음에 예측한 대로 자바 코드의 실행 방식 그대로 실행되는 코드의 결과를 확인할 수 있었다.

그에 따라서 인스턴스가 매 번 새롭게 생성되는 결과가 만들어지고 -> 테스트가 실패

이처럼 @Configuration 어노테이션을 사용하지 않는 경우, 바이트 코드를 조작하는 CGLIB 기술을 사용한 싱글톤의 보장이 이루어지지 않고, 이에 따라서 스프링 컨테이너를 활용한 스프링 빈의 관리가 이루어지지 않는 결과를 확인할 수 있었다.

그냥 스프링 빈이 컨테이너에 등록은 되는데, 스프링 빈을 사용할 때, 컨테이너에서 가져오지 않는 이상한 구조가 발생한다는 것으로 이해했다.

정리

@Bean 어노테이션만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 못함
- memberRepository()처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때, 싱글톤을 보장하지 않는다.
크게 고민할 것 없음 -> 스프링 설정 정보에는 항상 @Configuration 어노테이션을 사용해야 한다!!

728x90

'BackEnd > java spring' 카테고리의 다른 글

[Spring] 의존관계 자동 주입 (0)	2023.01.05
[Spring] 컴포넌트 스캔 (0)	2023.01.03
[Spring] 스프링 컨테이너와 스프링 빈 개념 정리 (0)	2022.12.31
IoC, DI 그리고 컨테이너 개념 정리 (0)	2022.12.28
Dependency Injection: 의존관계(의존성) 주입 개념 정리 (0)	2022.12.27

코딩 일지

[Spring] 싱글톤 컨테이너 개념 정리

웹 애플리케이션과 싱글톤

싱글톤 패턴

싱글톤 컨테이너

싱글톤 방식의 주의할 점

@Configuration과 싱글톤

@Configuration과 바이트코드 조작의 마법

@Configuration을 적용하는 이유가 뭘까?

'BackEnd > java spring' 카테고리의 다른 글

댓글

티스토리툴바

[Spring] 싱글톤 컨테이너 개념 정리

웹 애플리케이션과 싱글톤

싱글톤 패턴

싱글톤 컨테이너

싱글톤 방식의 주의할 점

@Configuration과 싱글톤

@Configuration과 바이트코드 조작의 마법

@Configuration을 적용하는 이유가 뭘까?

'BackEnd > java spring' 카테고리의 다른 글

관련글

댓글

티스토리툴바