스프링 핵심 원리 - (8)

싱글톤 컨테이너

웹 어플리케이션과 싱글톤

• 스프링은 엔터프라이즈 환경을 위해 탄생
• 보통 웹 어플리케이션
• 여러 요청이 인입

 

 

순수한 DI 컨테이너

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

• 호출 할때마다 객체를 새로 생성 -> 메모리 낭비 -> 싱글톤으로 해결

 

 

싱글톤 패턴 적용

• 인스턴스가 딱 1개만 생성
• get메소드로 생성된 인스턴스 반환하여 사용

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() {
  //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();
}

단점

• 코드가 더 필요하다
• 클라이언트가 구체 클래스에 의존
• 테스트 어렵
• 내부 속성 변경,초기화 어렵다
• private 생성자 사용으로 상속이 어렵다
• 결과적으로 유연성이 떨어진다
• 안티패턴으로도 불린다.

 

 

싱글톤 컨테이너

• 싱글톤의 문제를 해결하면서, 싱글톤으로 관리한다.
• Default로 빈을 싱글톤으로 관리한다.

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

주의점

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

 

 

상태를 유지할 경우 문제

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

public class StatefulServiceTest {
    @Test
    void statefulServiceSingleton() {
        ApplicationContext ac = new
            AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean("statefulService",
            StatefulService.class);
        StatefulService statefulService2 = ac.getBean("statefulService",
            StatefulService.class);
      
        //ThreadA: A사용자 10000원 주문
        statefulService1.order("userA", 10000);
        //ThreadB: B사용자 20000원 주문
        statefulService2.order("userB", 20000);
        //ThreadA: 사용자A 주문 금액 조회
        int price = statefulService1.getPrice();
        //ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
        System.out.println("price = " + price);
        assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }
​
    static class TestConfig {
        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }
}

• ThreadA -> userA
• ThreadB -> userB
• 라고 가정하면 공유되는 필드의 값이 변경되므로 문제가 생긴다.

 

 

 

@Configuration과 싱글톤

• MemberService / OrderService 모두 MemoryMemberRepository를 의존 -> 내부적으론 new MemoryMemberRepository를 2번 호출하는데 왜 싱글톤이 안깨질까?

// 모두 같은 빈이 생성됐다.
assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);

 

 

바이트 코드 조작을 통한 싱글톤 보장

• @Configuration이 적힌 클래스 또한 빈으로 등록된다.
• 하지만, 해당 클래스의 빈이 등록되는것이 아닌 XXXCGLIB가 빈으로 등록된다.
  • 스프링이 자바 코드마저 변환할 수는 없으므로 바이트코드 변환을 통해 싱글톤 보장

 

XXXCGLIB 예상 코드

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

• @Configuration이 있는 클래스를 상속받은 XXXCGLIB 생성
  • 이후 상위 타입으로 빈 호출이 가능하기 때문에
• 내부 @Bean이 붙은 메서드의 빈이 존재하면 컨테이너에서 반환, 없으면 새로 생성
• 위 과정을 통해 싱글톤을 보장해준다.
• @Configuration을 설정하지 않으면, 내부적으로 빈이 여러개 등록된다. 싱글톤 보장X(그냥 항상 쓰도록 하자)

---

컴포넌트 스캔

• @Bean 이나 .xml으로 빈 등록을 하였지만 -> 프로젝트가 커짐에 따라 반복작업 증가
• 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하도록 하는 컴포넌트 스캔 제공
• 의존관계 자동 주입하는 @Autowired도 제공

@Configuration
@ComponentScan(
    excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
) // 기존 @Configuration붙은 설정을 제외하기 위해 (일반적으론 필요없음)
public class AutoAppConfig {
}

1. 이후에 각 클래스에 @Component를 달아주면 @ComponentScan이 읽어 빈으로 등록한다.
   1. 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용
   2. @Componenet("name")을 통해 이름부여할 수 있다.
2. 의존관계 자동주입을 위해 생성자에 @Autowired를 달아준다.
   1. 이때 조회 전략은 타입이 같은 빈을 찾아서 주입한다.
   2. 생성자의 파라미터가 많아도 모든 파라미터의 타입을 조회

 

 

 

탐색 위치

@ComponentScan(
 basePackages = "hello.core",
}

• 탐색할 패키지의 시작 위치 지정 -> 해당 패키지 포함 하위까지 검색
• 지정하지 않으면 @ComponentScan이 붙은 클래스의 패키지가 시작 위치로
• 루트 패키지가 시작인 것이 좋다( + default 사용)
  • @SpringBootApplication도 루트 패키지에 위치하며 @ComponentScan도 포함하고 있다.

 

 

기본 스캔 대상

• @Componet / @Controller / @Service / @Repository / @Configuration -> 모두 @Component를 포함
  • @Controller : 스프링 MVC 컨트롤러로 인식
  • @Repository : DAO로 인식하고, 데이터 계층의 예외를 반환
  • @Configuration : 스프링 설정 정보로 인식하고, 싱글톤을 유지하도록 추가
  • @Service : 특별한 처리는 없지만, 비지니스 계층을 인식할 수 있도록 표시에 의미가 있다.
• 사실 애노테이션은 상속이 없으므로, 포함하고 있는 애노테이션을 인식하는것은 자바가 아닌 스프링의 기능이다.

 

 

필터

어노테이션 필터 생성

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {
}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {
}

 

 

어노테이션 필터 적용

@MyIncludeComponent
public class BeanA {
}

@MyExcludeComponent
public class BeanB {
}

 

 

테스트

public class ComponentFilterAppConfigTest {
    @Test
    void filterScan() {
      ApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);
      BeanA beanA = ac.getBean("beanA", BeanA.class);
​
      assertThat(beanA).isNotNull();
       Assertions.assertThrows(
          NoSuchBeanDefinitionException.class,
              () -> ac.getBean("beanB", BeanB.class));
    }
​
    @Configuration
    @ComponentScan(
        includeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)
    )
    static class ComponentFilterAppConfig {
    }
}

• BeanA는 등록, BeanB는 등록되지 않음
• 최근 스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데, 개인적으로는 옵션을 변경하면서 사용하기 보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장

 

 

중복 등록과 충돌

자동 빈 등록 vs 자동 빈 등록

• ConflictingBeanDefinitionException
• 컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생

 

수동 빈 등록 vs 자동 빈 등록

• 수동 빈 등록이 등록됨 (override)
• 스프링 부트에선 오류 발생
  • Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true
  • 설정값을 추가해줘야 override할 수 있다.