싱글톤 컨테이너

스프링을 적용하지 않은 순수한 DI 컨테이너

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

    assertThat(memberService1).isNotSameAs(memberService2);

}

 

• 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새롭게 생성
• 고객 트랙픽이 초댕 100이면 초당 100개의 객체가 생성되고 소멸
• 따라서 메모리 낭비가 심해진다.

 

 

싱글톤 패턴

• 스프링 없는 순수한 DI 컨테이너의 메모리 낭비를 해결하기 위한 디자인 패턴
• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장
• private 생성자를 사용해 외부에서 임의로 new 키워드를 사용하지 못하도록 한다.
  
  

//1. static 영역에 객체를 딱 1개만 생성
private static final SingletonService instance = new SingletonService();

//2. public으로 열어 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용
public static SingletonService getInstance() {
    return instance;
}

//3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 함
private SingletonService() {

}

 

• static 영역에 instance를 미리 하나만 생성해둔다.
• 이 객체의 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회가 가능하다.
• 때문에 이 메서드를 호출할 경우 항상 같은 인스턴스를 반환한다.
• 생성자를 private으로 막아 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.
• 싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라,
  이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다.

 

 

싱글톤 패턴의 문제점

• 이러한 싱글톤 패턴에는 문제점이 존재한다.
• 문제점은 다음과 같다
  • 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
  • 의존관계상 클라이언트가 구체 클래스에 의존한다. -> DIP를 위반
  • 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다
  • 테스트가 어렵다
  • 내부 속성을 변경하거나 초기화하기 어렵다
  • private 생성자로 자식 클래스를 만들기 어렵다.
  • 안티패턴으로 불리기도 한다.

 

 

싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결한다.
• 스프링 컨테이너에서 관리되는 스프링 빈은 싱글톤으로 관리된다.
• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
• 스프링 컨테이너는 싱글톤 패턴의 단점을 해결한다
  • 싱글톤 패턴을 위한 부가 코드가 들어가지 않아도 된다.
  • DIP, OCP, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
	//스프링 컨테이너 생성
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    //1. 조회 : 호출할 때마다 같은 객체를 생성
    MemberService memberService1 = ac.getBean("memberService", MemberService.class);

    //2. 조회 : 호출할 때마다 같은 객체를 생성
    MemberService memberService2 = ac.getBean("memberService", MemberService.class);

    //참조값이 같은 것을 확인
    System.out.println("memberService1 : "+memberService1);
    System.out.println("memberService2 : "+memberService2);

    //memberService1 == memberService2
    assertThat(memberService1).isSameAs(memberService2);

}

 

• 스프링 컨테이너를 적용하면 다음과 같이 객체가 반환된다.

스프링 컨테이너

 

 

싱글톤 방식의 주의점

• 싱글톤 방식은 객체 인스턴스를 하나만 생성해서 공유
• 따라서 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에
  싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.
• 싱글톤은 무상태(stateless)로 설계해야 한다.
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

 

 

@Configuration과 싱글톤

public class AppConfig {

    @Bean
    public MemberService memberService() {
        System.out.println("Call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        System.out.println("Call AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        System.out.println("Call AppConfig.orderService");
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }

 

• @Configuration을 적용한 AppConfig이다.
• 만약 위와 같이 출력 시 특정 문구를 출력하게 한다면 어떻게 될까?
• 예상은 다음과 같다.

 

* @Bean memberService를 호출하면
* memberRepository를 호출
* memberRepository는 MemoryMemberRepository를 호출
*
* @Bean orderService를 호출해도
* MemoryMemberRepository를 호출
*
* 예상
* Call AppConfig.memberService
* Call AppConfig.memberRepository
* Call AppConfig.memberRepository
* Call AppConfig.orderService
* Call AppConfig.memberRepository

 

• 하지만 실제 출력 결과는 다음과 같다

 

* 실제(싱글톤이 보장됨, 객체가 여러 개 생성 x)
* Call AppConfig.memberService
* Call AppConfig.memberRepository
* Call AppConfig.orderService

 

• @Configuration의 싱글톤이 보장되는 이유?
  • 스프링 컨테이너는 싱글톤 레지스트리
  • 스프링 컨테이너는 스프링 빈이 싱글톤이 되도록 보장
  • BUT 스프링이 자바 코드까지 싱글톤을 보장할 수는 없다.
  • 따라서 자바 코드 상으로는 memberRepositroy가 3번 호출되는 것이 맞다.
  • 하지만 실제로 한 번만 호출되는 것은 CGLIB 라이브러리 때문이다.

 

• 다음코드를 보자

AnnotationConfigApplicationContext applicationContext = 
	new AnnotationConfigApplicationContext(AppConfig.class);

AppConfig bean = applicationContext.getBean(AppConfig.class);

System.out.println("bean = " + bean.getClass());

// 기대 = class hello.core.AppConfig
// 실제 = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$4ab6406e

 

 

• AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다.
• 따라서 AppConfig도 스프링 빈이 된다.
• AppConfig 스프링 빈을 조회해서 클래스 정보를 출력하면 다음과 같다.

 

기대 = class hello.core.AppConfig
실제 = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$4ab6406e

 

 

• 이는 AppConfig가 순수한 클래스가 아니라는 것을 의미한다.
• 위와 같이 출력되는 것은 CGLIB라는 바이트코드 조작 라이브러리가 작용된 결과이다.
• 이 라이브러리는 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고,
  그 클래스를 스프링 빈으로 등록한다.
• 이 임의의 다른 클래스가 자바 코드 역시 싱글톤이 보장되도록 하는 것이다.
  
  

CGLIB 예상 코드

 

• 때문에 @Configuration을 등록하지 않고 @Bean만 등록하는 경우 싱글톤이 보장되지 않는다.

 

 

 

출처 : 인프런 김영한 님 스프링 강의