[스프링 핵심 원리 - 기본편] 인프런 강의 정리(싱글톤 컨테이너 - 웹 애플리케이션과 싱글톤, 싱글톤 패턴)

/* 이 글은 김영한님의 강의를 보고 정리하려고 작성한 글입니다.

   개인적인 공부를 위해 올리는 글이므로 중간 중간 코드는 생략되었습니다. */

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

 

 

 

 

 

웹 애플리케이션과 싱글톤

 

 

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

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

✔ 대부분의 스프링 애플리케이션은 웹 애플리케이션임(다른 애플리케이션 개발도 가능하긴 함)

✔ 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 함(위 그림 참조)

✔ 이렇게 요청을 할 때마다 객체를 생성한다면..? 아래에서 확인해보자.

 

 

 

 

2. 스프링 없는 순수한 DI 컨테이너 테스트

 

 

SingletonTest

public class SingletonTest {

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

        AppConfig appConfig = new AppConfig();

        // 호출할 때 마다 객체를 생성하는지 확인
        MemberService memberService1 = appConfig.memberService();
        MemberService memberService2 = appConfig.memberService();

        System.out.println("memberService1 = " + memberService1);
        System.out.println("memberService2 = " + memberService2);

        Assertions.assertThat(memberService1).isNotSameAs(memberService2);

    }

}

✔ 위 코드와 콘솔창을 보면 MemberService를 호출할 때 마다 객체를 새로 생성하는 것을 볼 수 있다.

✔ 만약 이렇게 설계된다면 고객 트래픽이 초당 100이 나오면 초당 100개의 객체가 생성되고 소멸될 것이다(메모리 낭비가 심함)

✔ 해결방안은 해당 객체가 딱 1개만 생성되고 그 객체를 공유하도록 설계하면 됨 

➔ 이것이 싱글톤 패턴!

 

 

 

 

 

3. 싱글톤 패턴

 

✔ 클래스와 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴.

✔ 객체 인스턴스를 2개 이상 생성되지 못하도록 막아야 함.

(private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.)

 

 

SingletonService

 

public class SingletonService {

    private static final SingletonService instance = new SingletonService();

    public static SingletonService getInstance(){
        return instance;
    }

    private SingletonService(){

    }

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

}

◾  1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.

◾  2. 이 객체 인스턴스가 필요하면 오직 `getInstance()` 메서드를 통해서만 조회할 수 있으며, 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.

◾  3. 딱 한 개의 객체 인스턴스만 존재해야 하므로, 생성자를 private로 막아서 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

 

 

 

 

SingletonTest

 

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
void singletonServiceTest() {

    SingletonService instance1 = SingletonService.getInstance();
    SingletonService instance2 = SingletonService.getInstance();

    System.out.println("instance1 = " + instance1);
    System.out.println("instance2 = " + instance2);

    Assertions.assertThat(instance1).isSameAs(instance2);

}

 

✔ 테스트를 하면 자바가 실행될 때 생성해놓은 SingletonService 인스턴스를 가져다 쓰는거라 같은 인스턴스 값이 나온다.

 

 

💡 궁금증1

:  isSameAs 랑 isEqualTo의 차이점?

 

◾ isSameAs

✔ ' == '와 같은 의미로 두 개의 객체 참조(메모리주소)가 동일한지 확인한다.

✔ 객체의 내용을 비교하지 않고, 참조값만 확인하므로 객체의 동일성을 확인하는데 사용된다.

 

◾ isEqualTo

✔ 두 객체의 내용이 동일한지 확인한다.

✔ 객체의 메모리 주소는 고려하지 않고 메서드에 의해 정의된 동등성을 확인하는데 사용된다.

 

 

 

4. 싱글톤 패턴의 문제점

 

✔ 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.

✔ 의존관계상 클라이언트가 구체 클래스에 의존한다 ➔ DIP를 위반한다.

✔ 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반한다.

✔ 테스트하기 어렵다.

✔ 내부 속성을 변경하거나 초기화하기 어렵다.

✔ private 생성자로 자식 클래스 만들기 어렵다.

✔ 결론적으로 유연성이 떨어지며 안티패턴으로 불리기도 한다.