스프링 코어(4) - 싱글톤(Singleton)에 대한 이해

이번 포스트에서부터는 싱글톤에 대해서 알아보겠습니다.

 

먼저 스프링에 대해 여담입니다.

• 태생 - 기업용 온라인 서비스 기술을 지원하기 위해 탄생
• 대부분의 스프링 애플리케이션 = 웹 애플리케이션
• 물론 Web이 아닌 것도 개발이 가능

 

웹 애플리케이션의 경우 보통

• 여러 명의 고객이
• 동시에 요청

하는 경우가 많습니다.

그리고 이전에 만든 것을 여기에 적용해 본다면

• 클라이언트A가 memberService를 호출합니다.
• 그러면 memberService1 객체가 생성됩니다.
• 클라이언트B가 memberService를 호출합니다.
• 그러면 memberService2 객체가 생성됩니다.
• ....

이렇게 된다면 100개의 요청이 들어오면 100개의 객체가 생성되고 소멸됩니다.
(→ 그다지 좋은 시스템인 것 같지는 않습니다...)

 

코드로 한 번 보겠습니다.

singleton이라는 패키지 생성 후 SingletonTest라는 자바 파일을 생성합니다.

import static org.assertj.core.api.Assertions.*;

public class SingletonTest {

    @Test
    public void pureContainer() {
        AppConfig appConfig = new AppConfig();
        /**
        *  memberService 객체를 하나 생성할 때마다
        *  mebmerRepository도 값이 생성된다. -> AppConfig에서 확인 가능
        *  그러니깐 2개의 memberService를 생성하면 총 4개의 객체가 생성되는 것이다!
        */
        // 1. 조회 : 호출할 때마다 객체 생성
        MemberService memberService1 = appConfig.memberService();
        MemberService memberService2 = appConfig.memberService();

        // 참조값이 다른지 확인해보기  ->  주소값이 다르므로 다른 객체가 생성되는 것을 확인할 수 있음
        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        // memberService1 != memberService2
        assertThat(memberService1).isNotSameAs(memberService2);
    }
        
}

이렇게 작성합니다. 

주석으로도 작성해서 대충 알겠지만

먼저 memberService 객체를 생성합니다.

그리고 그 2개 객체의 참조값이 다른지 확인해봅니다.

실제로 다른 것을 확인할 수 있습니다.

그리고 AppConfig를 보면 알 수 있지만, AppConfig에서 MemberService를 호출하면

MemberRepository도 같이 생성되기 때문에 2개의 객체가 생성됩니다.

즉, memberService가 2개 생성되면 총 4개의 객체가 생성됩니다.

 

이렇게 객체를 계속 생성하는 것은 메모리 낭비가 굉장히 심합니다.

유명한 어플리케이션의 경우에는 50000TPS 정도 된다고 합니다.

즉, 5만개의 객체가 매초마다 생성되어야 한다는 것입니다.

참 비효율적이라고 볼 수 있습니다.

 

이런 비효율적인 면을 해결할 수 있어야합니다.

→ 바로 객체가 1번 생성된 후 공유를 하면 해결이 될 수 있습니다.

→ 이것이 바로 Singleton 패턴입니다.

 

Singleton 패턴에 대해서는 다음에 알아보겠습니다.

 

 

 

 

출처: 인프런 - 스프링 핵심원리(기본편) by 김영한