[Spring] 웹 애플리케이션과 싱글톤

이번 포스팅부터는 싱글톤 컨테이너에 대해 알아보자. 싱글톤 패턴은 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴하는 것을 말한다. 

---

 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다. 그래서 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 할 수 있다. 

 웹 애플리케이션은 보통 여러 클라이언트가 동시에 요청을 한다. 

위 상황에서 클라이언트가 3번의 요청을 하면 3개의 객체가 생성된다. 이렇게 되면 요청이 올 때마다 계속 객체를 생성해야 하는 문제가 발생한다. 이를 코드를 이용해 테스트를 해보자. 다음은 스프링을 사용하지 않은 DI 컨테이너이다. 

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 static org.assertj.core.api.Assertions.*;

public class SingletonTest {

    @Test
    @DisplayName("스프링이 없는 순수한 DI 컨테이너")
    void pureContainer(){
        AppConfig appConfig = new AppConfig();
        //1. 조회: 호출할 때 마다 객체를 생성
        MemberService memberService1 = appConfig.memberService();
        //2. 조회: 호출할 때 마다 객체를 생성
        MemberService memberService2 = appConfig.memberService();
        //참조값이 다른 것을 확인
        System.out.println("memberService1 = " + memberService1); 
        System.out.println("memberService2 = " + memberService2);
        
        //memberService1 != memberService2
        assertThat(memberService1).isNotSameAs(memberService2);
    }
}

먼저 조회할 때마다 객체를 생성하므로, 2개의 객체를 생성하고 이를 출력해 참조값이 다른 것을 확인해보자. 이를 실행해보면 다음과 같은 결과를 얻을 수 있다.

1과 2의 객체가 다른 것을 알 수 있고, 이렇게되면 호출할 때마다 JVM의 메모리에 계속해서 객체가 생성되어 올라갈 것이다.

 

우리가 과거에 만들었던 스프링이 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성한다. 만약 고객 트래픽이 초당 100이 나온다면 초당 100개의 객체가 생성되고 소멸된다. 이는 메모리의 낭비로 이어진다. 이를 해결할 수 있는 방안은

객체가 딱 1개만 생성되고 공유하도록 설계하자! 이것이 싱글톤 패턴이다. 

---

다음 포스팅에서 싱글톤 패턴을 적용하여 이 문제를 해결해보자.