Singleton Container

□ 스프링 없는 DI 컨테이너로 구성된 경우

• 스프링 없는 순수한 DI 컨테이너인 AppConfig를 요청할 때마다 새로 생성한다.
  • ex) 트래픽이 초당 100인 경우 초당 100개 객체가 생성되고 소멸된다. → 메모리 낭비가 심하다.
  • 싱글톤 패턴으로 해결 가능

 

□ 싱글톤 컨테이너를 적용 후

 

싱글톤 패턴

• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.
• 객체 인스턴스를 2개 이상 생성하지 못하게 막아야 한다.

 

□ 싱글톤 예제 코드

 public class SingletonService {
    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();
    
    //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingletonService getInstance() {
         return instance;
    }
    
    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다. 
    private SingletonService() { }
    
    public void logic() { 
    	System.out.println("싱글톤 객체 로직 호출");
    } 
}

 

□ 싱글톤 패턴 테스트 코드

@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용") 
public void singletonServiceTest() {
    //private으로 생성자를 막아두었다. 컴파일 오류가 발생한다.
    //new SingletonService();
    
    //1. 조회: 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService1 = SingletonService.getInstance(); 
    
    //2. 조회: 호출할 때 마다 같은 객체를 반환
    SingletonService singletonService2 = SingletonService.getInstance();
    
    //참조값이 같은 것을 확인
    System.out.println("singletonService1 = " + singletonService1); 
    System.out.println("singletonService2 = " + singletonService2);
    
    // singletonService1 == singletonService2
    assertThat(singletonService1).isSameAs(singletonService2);
    singletonService1.logic();
}

 

해당 코드에는 문제점이 존재한다.

 

 

□ 문제점

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

 

싱글톤 컨테이너

• 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
  • 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.

 

□ 스프링 컨테이너를 사용한 테스트 코드

@Test
@DisplayName("스프링 컨테이너와 싱글톤") 
void springContainer() {
    ApplicationContext 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);
}

• 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
  • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
  • DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

 

주의점

• stateless(무상태)로 설계해야 한다.
  • 특정 클라이언트에 의존적인 필드가 있으면 안 된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 된다.
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

 

□ 자바 코드 설정 파일

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
         return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public OrderService orderService() {
         return new OrderServiceImpl(
                 memberRepository(),
                 discountPolicy());
    }
    
    @Bean
    public MemberRepository memberRepository() {
         return new MemoryMemberRepository();
    }
	... 
}

해당 코드를 유심하게 보면

 

memberService()를 호출하는 경우 memberRepository()를 호출하여 MemoryMemberRepository객체가 생성된다.

orderService()를 호출하는 경우 memberRepository()를 호출하여 MemoryMemberRepository객체가 생성된다.

이런 경우 각각 2개의 MemoryMemberRepository 객체가 생성되는 것이 아닐까?

 

□ 위 상황을 위한 테스트 코드

public class ConfigurationSingletonTest {
    @Test
    void configurationTest() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        //모두 같은 인스턴스를 참고하고 있다.
        System.out.println("memberService -> memberRepository = " + memberService.getMemberRepository());
        System.out.println("orderService -> memberRepository  = " + orderService.getMemberRepository());
        System.out.println("memberRepository = " + memberRepository);
        
        //모두 같은 인스턴스를 참고하고 있다.
        assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
    }
}

테스트 결과를 보면 MemoryMemberRepository 객체가 2번 생성되는 것이 아닌 1개의 객체를 생성하는 것을 알 수 있다.

 

왜 그런 걸까?

Configuration 살펴보면 알 수 있다.

@Configuration

□ 스프링 빈에 등록된 클래스 정보를 알아보는 코드

@Test
void configurationDeep() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    
    //AppConfig도 스프링 빈으로 등록된다.
    AppConfig bean = ac.getBean(AppConfig.class);
    System.out.println("bean = " + bean.getClass());
	//출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70 
}

출력 결과를 보면 AppConfig$$xxxxxxxCGLIBxxxxx 이러한 형태로 출력되어 있다.

 

스프링 빈에 등록할 때 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들어 스프링 빈에 등록한 것이다! (@Configuration 내부에 CGLIB 라이브러리가 있다.)

 

 

이를 통해 예상할 수 있는 것은

CGLIB 내부 코드에서 MemoryMemberRepository 객체가 스프링 컨테이너에 생성되어 있다면 찾아서 return 하고,

없다면 MemoryMemberRepository 객체를 생성하여 스프링 컨테이너에 등록한다는 것을 예상할 수 있다.

 

# 참고한 자료

• 인프런 김영한 님 강의