[섹션5-1] 웹 어플리케이션과 싱글톤 ( 순수 DI컨테이너의 문제점 )

 

 

우리는 스프링 애플리케이션을 이용해서 주로 웹 애플리케이션 개발을 한다. 

웹 애플리케이션의 경우 여러 고객이 동시에 요청을 한다. 

 

 

우리가 스프링을 이용하지 않는 순수한 자바 코드로만 만들어본 DI컨테이너를 이용한다면

   (스프링 컨테이너를 생성하지 않고 AppConfig 를 이용해서 객체를 생성하고 주입 받는 방법) 

 

public MemberService memberService(){

    return new MemberServiceImpl(memberRepository());
}

 

 

 

세명의 고객이 요청을 하면  객체도 3개 생성되는 것이다. 

 

만약 만명의 고객이 동시에 요청하면   새로운 객체를 만개를 만들어야 한다는 것인데 이것은 매우 비효율적이며 메모리의 낭비가 심할 것이다. 

 

 

즉, 스프링이 없는 순수한 DI컨테이너는  고객의 요청이 올때마다 새로운 객체를 만들어야한다는 문제점이 있다.

 

 

 

 

 

그렇다면 코드로 고객의 요청이 올때마다 새로운 객체가 생성되는지 알아보자

 

SingletoneTest 

•   순수 DI 컨테이너는 요청이 올 때 마다 새로운 객체를 생성하는지 알아보는 테스트 코드

public class SingletoneTest {


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

}

 

// 실행결과 

memberService1 = hello.core.member.MemberServiceImpl@2145433b
memberService2 = hello.core.member.MemberServiceImpl@2890c451

 

 

코드 실행 결과 요청을 받을 때 마다 새로운 객체를 생성한다는 것을 알 수 있다. 

 

그렇다면 요청이 들어올 때 마다 새로운 객체를 만들지 말고, 하나의 객체를 공유해서 사용할 순 없을까? 

이와 관련된 것이 바로 싱글톤 방식이다. 

 

다음 글에서 싱글톤에 대해 알아보자. 

 

 

정리

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