26. 웹 애플리케이션과 싱글톤

이번에는 싱글톤 컨테이너를 알아보았다.

싱글톤 패턴은 정보처리기사에서 디자인 패턴

부분에서 봤던 내용이다.

 

웹 애플리케이션과 싱글톤

 

스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다.

대부분의 스프링 애플리케이션은 웹 애플리케이션이다.

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.

 

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/lecture/55361?speed=0.75&tab=note&mm=close

클라이언트 A,B,C 가 동시에 요청을 한다면?

DI 컨테이너는 새로운 객체를 3개를 생성하여 반환한다.

이때 웹 어플리케이션은 계속 요청을 받아야만 하기때문에

객체를 계속 만들어야하는 문제가 발생한다.

 

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;

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

    }
}

참조값을 확인하기 위한 테스트 코드를 작성해보았다.

 

@뒤에 부분이 다르다 

즉 두 객체는 다른것이다. 

웹 어플리케이션의 특징은 고객의 요청이 어마어마하다는 것이다.

이런식으로 객체를 계속 생성하는것은 비효율 적이다.

 

내가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청할때마다 객체를 생성한다.

고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다. -> 메모리 낭비

해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. -> 싱글톤 패턴