[spring] 싱글톤 컨테이너

웹 애플리케이션과 싱글톤

• 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 할 수 있다.
• 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.
  

스프링 없는 순수한 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);
    }
}

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

싱글톤 패턴

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
• 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하게 막아야 한다.

싱글톤 패턴을 적용한 예제코드 이다.

• static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
• 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반복한다.
• 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

  싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. 하지만 싱글톤 패턴은 여러 문제점이 있다.

싱글톤 패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. → DIP 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트가 어렵다.
• 내부 속성을 변경, 초기화가 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.