스프링 핵심 원리 이해 4 - 싱글톤 컨테이너

• 발생 원인
  • 순수 자바 컨테이너로 만들었던 AppConfig를 웹 애플리케이션으로 직접 사용하면 요청할 때마다 설정파일 내의 객체를 새로 생성하고 삭제하는 과정을 거친다.
  • 메모리 낭비가 심하다.

@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer(){
    AppConfig appConfig = new AppConfig();
    
    MemberService memberService1 = appconfig.memberService();
    MemberService memberService2 = appconfig.memberService();
    
    assertThat(memberService1).isNotSameAs(memberService2);
}

 

•  해결방안
  • 해당 객체를 1개만 생성하고 공유하도록 설계 한다. == 싱글톤 패턴

• 싱글톤 
  • 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
  • private constructor를 사용해서 외부에서 new keyword를 사용하지 못하도록 한다.

 

1. 싱글톤 패턴

• 싱글톤 패턴 적용시, 요청 때 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용한다.
  
  
• 싱글톤 패턴 작성
  
  1. 싱글톤을 적용할 class의 instance를 해당 class 내부에 작성
     private static final ClassType instance = new ClassType(){};
  2. 해당 객체 사용하려면 getter를 통해서만 사용하도록 한다.
     public static ReturnType getter() {};
  3. 생성자를 private으로 선언해서 해당 class instance 생성을 막는다.
     private ClassName () {}
• JUnit5 
  • isSameAs() : java의 == 과 동일, 객체 주소까지 비교 의미
  • equeals() : java의 equals와 동일, 주소가 아닌 값 비교 의미

@Test
@DisplayName("싱글톤 패턴 적용한 객체 시용")
public void singletonServiceTest(){
    SingletonService singletonService1 = SingletonService.getInstance();
    SingletonSErvice singletonService2 = SingletonService.getInstance();
    // new SingletonService(); // error
    asserThat(singletonService1).isSameAs(singletonService2);
}

// [다른 class]
// 싱글톤 패턴을 적용한 class
public class SingletonService{
	// static 영역에 객체를 딱 1개만 생성한다.
    private static final SingletonService instance = new SingletonService();
    // public으로 열어서 객체 인스턴스가 필요시, 이 static 메서드를 통해서만 조회
    public static SingletonService getInstance(){
    	return instance;
    }
    // 생성자를 private으로 선언, 외부에서 new keyword 사용한 객체 생성 막음
    private SingletonService(){};
}

• singleton 패턴 문제점
  • 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
  • 의존관계상 클라이언트가 구체 클래스에 의존한다.   DIP를 위반한다. ex) getInstance()로 직접 구현체 가져옴
  • 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
  • 테스트하기 어렵다.
  • 내부 속성을 변경하거나 초기화 하기 어렵다.
  • private 생성자로 자식 클래스를 만들기 어렵다.
  • 결론적으로 유연성이 떨어진다.

 

• Spring Container
  • 싱글톤 컨테이너라고 한다.
  • 빈을 저장할 때 싱글톤 방식으로 저장한다.
  • 해당 패턴의 문제점을 전부 보완했다.

 

2. 싱글톤 컨테이너

• 스프링 컨테이너 : 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.
• 스프링 컨테이너의 Spring Bean은 싱글톤으로 관리되는 Bean

    @Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void SpringContainer(){
        // AppConfig appConfig = new AppConfig();
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);

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

        Assertions.assertThat(memberService1).isSameAs(memberService2);
    }

 

• 정리
  • 스프링 컨테이너: 싱글톤 컨테이너 역할 수행
  • 싱글톤 레지스트리: 싱글톤 객체를 생성하고 관리하는 기능
    
    
  • 스프링 컨테이너 싱글톤의 장점
    • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
    •  DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다. 
    • 스프링 컨테이너 덕분에 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.
  • 참고
    • 스프링의 기본 빈 등록 방식은 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아니다.
    • 빈스코프 기능 제공 : 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능 제공

 

 

⭐️ 3. 싱글톤 방식의 주의점

• 하나의 객체를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안 된다.
  • 싱글톤뿐만이 아니라 하나의 객체를 공유하는 부분은 아주아주 주의 필요
    다른 client로 인해서 현 client data가 변경되기 때문
• 무상태(stateless) 설계
  1. 특정 client에 의존적인 필드가 있으면 안 된다. = only read
  2. 특정 client가 값을 변경할 수 있는 필드가 있으면 안된다.
  3. 필드 대신에 java에서 공유되지 않는 lv, params, ThreadLocal 등을 사용

 

• stateful 문제점 코드

public class StatefulService{
    private int price; // 상태를 유지하는 필드
    
    public void order(String name, int price){
    	System.out.println("name= " + name + " price = " + price );
        this.price = price;
    }
    public int getPrice(){ 
        return price; 
    }; 
}

package hello.core.singleton;

class StatefulServiceTest {
    @Test
    void statefulServiceSingleton() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        // @Configuration 없이 해당 class를 통채로 스프링컨테이너에 등록. 내부에는 @Bean이 있긴 해야함
        StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
        StatefulService statefulService2 = ac.getBean("statefulService",StatefulService.class);

        statefulService1.order("a", 10000);
        statefulService1.order("b", 20000);

        int price = statefulService1.getPrice();
        assertThat(price).isEqualTo(20000);
    }

    static  class TestConfig {
        @Bean
        public StatefulService statefulService(){
            return new StatefulService();
        }
    }
}

• 싱글톤 주의 사항 위배
  • StatefulService의 price 필드는 공유필드인데, 특정 클라이언트가 값을 변경
• 진짜 공유필드는 조심해야 한다! 스프링 빈은 항상 무상태(stateless)로 설계
  
  • 지역변수를 통해서 price를 출력하도록 한다.

 

• stateful 문제점 해결

// 변경 전
public class StatefulService{
    private int price; // 값 공유 하는 이 부분이 문제 = stateful 하다
    public void order(String name, int price){ this.price = price; }
    public int getPrice(){ return price; };
}

// 변경 후
public class StatelessService{
      public int order(String name, int price){
          return price; // 지역변수로 값을 넘겨준다 = stateless 하다
    }
}

// TEST 변경 전
@Test
void statfulServiceSingleton(){
    '''생략'''
    statefulService1.order("userA", 10000);
    statefulService1.order("userB", 20000);
    int price = statefulService1.getPrice();
    Assertions.asserThat(price).isEqualTp(20000); // userA는 10000원인데 20000원이 나옴
    
}

//// TEST 변경 후
@Test
void statfulServiceSingleton(){
    '''생략'''
     // 지역변수 price 값을 담는 int 변수 생성
    int userAPrice = statefulService1.order("userA", 10000);
    int userBPrice = statefulService1.order("userB", 20000); 
    Assertions.asserThat(price).isEqualTp(10000); // userA는 10000원 나옴
    
}

 

 

4. @Configuration, 싱글톤

• @Configuration 은 싱글톤을 위해서 존재한다.
  
  
• AppConfig (@Configuration 존재)
  • memberReopsitory()를 2번 호출 -> 생성자를 이용한 객체 생성이므로 싱글톤을 위배한 것이 정상적인 java 동작 방식
  • 하지만 test를 수행하면 싱글톤이 깨지지 않는다. ->모두 동일한 인스턴수가 공유

@Configuration
public class AppConfig {

    @Bean // spring container 에 넣기
    public MemberRepository memberRepository() { return new MemoryMemberRepository(); }
    @Bean
    public DiscountPolicy discountPolicy() { return new RateDiscountPolicy(); }

    @Bean
    public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } // 1번
    @Bean
    public OrderService orderService(){ return new OrderServiceImpl(memberRepository(), discountPolicy()); } // 2번
}

• test1

public class SingleTonTest {

    @Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용")
    void singletonServiceTest() {
        SingletonService singletonService1 = SingletonService.getInstance();
        SingletonService singletonService2 = SingletonService.getInstance();

        System.out.println("singletonService2 = " + singletonService2);
        System.out.println("singletonService1 = " + singletonService1);

        Assertions.assertThat(singletonService1).isSameAs(singletonService2);
    }

    @Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void SpringContainer(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService1 = ac.getBean("memberService", MemberService.class);
        MemberService memberService2 = ac.getBean("memberService", MemberService.class);

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

        Assertions.assertThat(memberService1).isSameAs(memberService2);
    }
}

• test

package hello.core.singleton;

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

            MemberRepository memberRepository1 = memberService.getMemberRepository();
            MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println(memberRepository1);
        System.out.println(memberRepository2);
        System.out.println(memberRepository);

        Assertions.assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        Assertions.assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);

    }

    @Test
    void configurationDeep(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        AppConfig bean = ac.getBean(AppConfig.class);
        System.out.println("bean = " + bean);
        System.out.println("bean.getClass = " + bean.getClass());
    }
}

 

5. @Configuration과 바이트코드 조작의 마법

@Test
void configurationDeep(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    AppConfig bean = ac.getBean(AppConfig.class);
    // CGLIB
    System.out.println("bean = " + bean); // hello.core.AppConfig$$SpringCGLIB$$0@37e4d7bb
    System.out.println("bean.getClass = " + bean.getClass()); // hello.core.AppConfig$$SpringCGLIB$$0
}

5.1. 싱글톤이 유지되는 이유

• spring은 클래스의 바이트코드를 조작하는 라이브러리를 사용 ( 라이브러리 = CGLIB )
• @Configuration이 포함된 AppConfig: CGLIB를 이용해서 조작된 AppConfig$$SpringCGLIB$$0@74a6f9c1 로 springContainer에 등록
• @Bean 객체 : 해당 조작AppConfig를 통해 싱글톤이 적용되도록 springContainer에 등록

 

5.2. @Configuration

1. @Configuration은 사실 singleton을 위해 존재
2. @Configuration을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장
3. @Configuration 없이 @Bean만 존재해도 springContainer에 등록이 가능: 하지만 싱글톤이 유지가 안된다.

• 작동방식
  1. spring은 @Configuration 존재 설정파일을 찾는다.
  2. 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 AppConfig@CGLIB를 만든다.
  3. 새로 만들어진 AppConfig@CGLIB로 @Bean을 등록한다.
  4. 등록 시 동일 인스턴스를 사용하면 springContainer에 미리 생성된 객체를 사용
  5. 해당 인스턴스가 없으면 생성한다.
• 결론: 싱글톤이 보장되도록 해준다
• 그림

• CGLIB 예상 로직

// AppConfig@CGLIB 예상 로직

@Bean public MemberRepository memberRepository() {

    if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
    	return 스프링 컨테이너에서 찾아서 반환;
    } else { //스프링 컨테이너에 없으면
    	기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
    	return 반환
    }
}

 

6. BeanDefinition 과 CGLIB

• BeanDefinition과 @Configuration의 CGLIB 작동 순서
  1. @Configuration이 붙은 클래스는 CGLIB를 사용하여 자바 프록시 객체를 생성
  2. @Bean이 붙은 메서드는 해당 클래스의 프록시 객체 내부에서 호출
  3. @Bean 메서드에서 생성된 객체는 해당 클래스의 프록시 객체 내부에 등록
  4. @Bean 메서드에서 생성된 객체는 BeanDefinition이라는 객체로 변환되어 스프링 컨테이너에 등록
• 정리
  • @Configuration이 붙은 클래스는 CGLIB를 사용하여 프록시 객체를 생성하고, 해당 클래스 내부의 @Bean 메서드에서 생성된 객체들은 BeanDefinition 객체로 변환되어 스프링 컨테이너에 등록
  • 이렇게 생성된 BeanDefinition 객체들은 스프링 컨테이너가 시작될 때 미리 생성되어 관리

 

 

 

이전 발행글: 스프링 핵심 원리 이해 3 - 스프링 컨테이너와 스프링 빈

 

다음 발행글: 스프링 핵심 원리 이해 5 - 컴포넌트 스캔