스프링 싱글톤 컨테이너의 동작 원리

📔 웹 어플리케이션과 싱글톤

스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다. 그렇기에 대부분의 스프링 어플리케이션은 웹 어플리케이션이다. 웹 어플리케이션의 특징은, 보통 여러 고객이 동시 요청을 보낸다는 점이다. 그렇다면 어플리케이션이 커지고, 트레픽이 많아질 수록, 객체 생성 비용과 메모리 사용량은 증가하게 되고, 많은 리소스를 소모한다는 뜻이다. 

 

다음은, 스프링이 없는 순수한 DI 컨테이너 테스트 예시이다.

 

public class SingletonTest {
    
    @Test
    @DisplayName("스프링 없는 순수 DI 컨테이너")
    void pureContainer(){

        AppConfig appConfig = new AppConfig();

        MemberService memberService1 = appConfig.memberService();
        
        MemberService memberService2 = appConfig.memberService();
        
        System.out.println("1 : " + memberService1);
        System.out.println("2 : " + memberService2);

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

 

결과를 보면, 참조값도 다르고, isNotEqualTo 테스트도 통과되는 것을 볼 수 있다.

이 테스트의 의미는, 순수한 DI Container인 AppConfig는 요청마다 객체를 새로 생성한다. 물론 요청 수가 적다면 상관 없을 것이다. 하지만, 만약 고객 트래픽이 초당 100이라면, 초당 100개의 객체가 생성되고 소멸되는데, 메모리 낭비가 매우 심하다.

 

이 문제를 해결하기 위해 싱들톤 패턴을 사용한다.

📔싱글톤 패턴

싱글톤 패턴이란, 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 그렇기에 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.

• 생성자를 private 을 사용하여, 외부에서 임의로 new 키워드로 객체를 생성하는것을 막는다.

다음은 싱글톤 패턴의 예시이다.

public class SingletonService {

    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance(){
        return instance;
    }

    private SingletonService(){
    }

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

• static 영역에 객체 instance 를 미리 하나 생성하여 올려둔다
• 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 호출이 가능하다
• 딱 1개의 객체 인스턴스만 존재해야 하므로 생성자를 private 으로 설정하여 외부에서 new 키워드로의 접근을 막아야 한다.

한번 이 싱글톤이 진짜 싱글톤인지 확인해 보자. 이전 DI 테스트에선, 두개의 인스턴스를 생성하면 참조값이 서로 달랐던 것을 기억하자.

 

    @Test
    @DisplayName("싱글톤 객체 테스트")
    void singletonServiceTest(){
        SingletonService singletonService1 = SingletonService.getInstance();
        SingletonService singletonService2 = SingletonService.getInstance();
        
        System.out.println("1 : " + singletonService1);
        System.out.println("2 : " + singletonService2);
        
        Assertions.assertThat(singletonService1).isSameAs(singletonService2);
        
        singletonService1.logic();
    }

 

결과

싱글톤 패턴의 문제점

싱글톤 패턴은 객체를 공유하여 효율적으로 사용할 수 있지만, 수많은 문제점들을 가지고 있다.

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. → DIP 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙의 위반할 가능성이 높다.
• 테스트 하기 어렵다
• 내부 속성을 변경하거나 초기화 하기 어렵다
• private 생성자로 자식 생성자로 자식 클래스를 만들기 어렵다.
• 유연성이 떨어진다

 

📔 싱글톤 컨테이너

Spring Container 는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리한다. Spring Bean 은 기본적으로 싱글톤으로 관리된다.

 

싱글톤 컨테이너

• Spring Container 는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.
• Spring Container 는 싱글톤 컨테이너 역할을 한다. → 싱글톤 객체를 생성하고 관리하는 기능을 Singleton Registry라 한다.
• Spring Container 의 이런 기능 덕에 싱글톤의 모든 단점을 해결하면서, 객체를 싱글톤으로 유지할 수 있다.

 

    @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("1 : " + memberService1);
        System.out.println("2 : " + memberService2);

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

 

이전 테스트는 직접 작성한 싱글톤 클래스의 테스트였다. 이번 테스트는 Spring Container 에 등록되어 컨테이너가 bean 들을 싱글톤으로 관리하는지 검증하기 위한 테스트이다. 참조값도 같고 테스트도 통과한다.

 

싱글톤 컨테이너 적용 후 모습

 

📔싱글톤 방식의 주의점

싱글톤은 이전에 언급했듯, 여러 사용자가 공유하는 객체 인스턴스이다. 그렇기 때문에, 싱글톤 객체는 상태를 유지해선 안된다. (Stateless)

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

Stateful 예시

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

public class StatefulServiceTest {

    @Test
    void statefulServiceSingleton(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);

        StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
        StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);

        statefulService1.order("userA", 10000);
        statefulService2.order("userB", 20000);

        int price = statefulService1.getPrice();

        System.out.println(price);

        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

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

 

price 를 조회하면, 우리의 의도대로라면 10000원이어야 한다. 하지만, 실제 실행 결과는 20000이 나온다.. → 같은 인스턴스를 공유하기 때문.

 

그래서 우리는 다음과 같이 설계를 해야 한다

public class StatefulService {

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

//    public int getPrice(){
//        return price;
//    }
}

    @Test
    void statefulServiceSingleton(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);

        StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
        StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);

        int userA = statefulService1.order("userA", 10000);
        int userB = statefulService2.order("userB", 20000);


        System.out.println(userA);

        // Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

 

@Configuration 과 싱글톤

이전에 생성한 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();
 }
 ...
}

• memberService 에서 호출하는 memberRepository 는 new 키워드로 생성이 되고, orderService 에서 호출하는 memberRepository 또한 new 키워드로 생성이 된다.
• 그렇다면 싱글톤이 깨지는 것일까?

결론부터 말하자면, 싱글톤은 깨지지 않는다. 테스트로 검증해 보자.

각 OrderServiceImpl 과 MemberServiceImpl 에 memberRepository 를 반환하는 임시 메서드를 만든 후, 테스트를 작성하자.

    @Test
    void configurationTest() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        System.out.println("1 : " + memberService.getMemberRepository());
        System.out.println("2 : " + orderService.getMemberRepository());
        System.out.println("3 : " + memberRepository);

    }

모두 같은 참조값을 가르키고 있다.

한번 AppConfig 에 로그를 찍어 확인해 보자.

    @Bean
    public MemberService memberService(){
        System.out.println("Calling memberService");
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService(){
        System.out.println("Calling orderService");
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository(){
        System.out.println("Calling memberRepository");
        return new MemoryMemberRepository();
    }

 

분명 memberService 에서도, orderService 에서도 memberRepository 메서드를 통한 new 키워드를 사용하기에, “Calling memberRepository” 가 3번 출력되어야 할 것 같다. 하지만 결과는 다음과 같다

 

memberRepository 는 단 한번만 호출된다.

@Configuration 과 바이트 코드 조작

Spring 의 Bean 은 기본적으로 싱글톤 Scope 를 가진다고 이미 설명했다. Spring 은 이를 어떻게 보장할까?

CGLIB 프록시를 통해 싱글톤을 보장한다. @Configuration이 붙은 클래스의 Bean 들을 스프링은 런타임시, CGLIB Proxy 로 감싸서 메서드 호출을 가로챈다. 즉, @Configuration 클래스 내에서 다른 @Bean 메서드를 호출 하더라도, 실제로 해당 메서드가 실행 되는 것이 아닌, 프록시가 가로채는 형식으로 작동하는 것이다.

CGLIB를 통한 프록시 생성

1. Spring 은 원본 @Configuration 클래스를 상속받는 프록시 서브클래스를 생성한다. 이 프록시 클래스는 원본 클래스의 모든 메서드를 오버라이드 한다
2. CGLIB는 바이트 코드 수준에서 클래스의 메서드를 조작하는 새로운 기능을 추가하여, 메서드 호출을 가로채거나 원하는 로직을 삽입한다.
3. 오버라이드된 @Bean 메서드 들은 실제로는 Spring 컨테이너에서 Bean 을 조회 / 생성하는 로직을 포함한다. 이로써, 클래스의 메서드 호출시, 본문이 아닌 컨테이너를 통해 관리된 Bean 이 반환되는 것이다.

동작 과정

1. 컨테이너 초기화시, memberService() 가 호출되고, 이 안에서 memberRepository() 가 호출된다. 이때, 프록시 메서드는 컨테이너에 memberRepository Bean 이 존재하는지 확인하는데, 없으므로, super.memberRepository() 를 호출하여 원본 메서드의 본문을 실행하고 Bean 을 생성 및 컨테이너에 등록하게 된다.
2. memberRepository 의 두번째, 세번째 호출시, 프록시 메서드는 컨테이너에 해당 bean 이 이미 존재함을 확인하고, 원본 메서드의 본문을 실행하는 대신, 컨테이너에 등록된 기존의 싱글톤 bean 을 반환하게 된다.

    @Test
    void configurationDeep(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        
        AppConfig bean = ac.getBean(AppConfig.class);
        
        System.out.println("bean = " + bean.getClass());
    }

• 사실 AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 Spring Bean 으로 등록이 된다.

출력결과

bean = class hello.core.AppConfig$$SpringCGLIB$$0

 

즉, 우리가 사용하는 클래스는, 우리가 생성한 클래스가 아닌, CGLIB 라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 를 상속받은 임의의 다른 클래스를 스프링 빈으로 등록한 것이다.

이를 통해 싱글톤이 보장된다.

한번 @Configuration 어노테이션을 지우고 실행해 보자

 

이전과 달리 memberRepository 가 3번 호출되는것을 볼 수 있다.

 

정리

• 싱글톤 패턴은 객체 재사용 측면에서 효율적이지만, 직접 구현 시 유연성, 테스트성, 유지보수성 측면에서 어려움을 겪는다.
• 스프링 컨테이너는 별도의 구현 없이 Bean을 싱글톤으로 관리해 이 문제를 해결한다.
• 싱글톤으로 Bean을 관리할 때는 상태를 가지지 않도록 주의해야 한다.
• @Configuration과 CGLIB 프록시를 통해 스프링은 동일한 Bean을 요청 시 항상 같은 인스턴스를 반환하는 메커니즘을 갖추고 있다.
• 다중 사용자 요청이 발생하는 웹 애플리케이션 환경에서는 특히 주의해야 하며, Stateless 설계를 통해 안전하고 일관성 있는 애플리케이션을 구축할 수 있다.