SpringBoot Part1-3

 

1. Circular Dependency (원형 의존성)

 

- 두 개 이상의 객체 간에 서로가 서로에 대해 의존하는 상황

- A -> B를 참조하는 동시에  B -> A를 참조

- BeanCurrentlyInCreationException 예외가 발생할 수 있다.

 

Circular Dependency의 문제점

 

@Configuration
class CircularConfig{
    @Bean
    public A a (B b) {
        return new A(b);
    }

    @Bean
    public B b(A a) {
        return new B(a);
    }
}

- 어느 빈을 먼저 생성하고 주입해야 하는지 판단하기 어렵다. -> BeanCurrentlyInCreationException 발생

- 의존성 주입이 순환적으로 계속되는 경우, 무한 루프가 발생할 수도 있다.

 

해당 문제점을 해결하기 위한 방법은 하단 블로그 참고!

https://www.baeldung.com/circular-dependencies-in-spring

---

2. Component Scan

 

스프링이 직접 클래스를 검색해서 빈으로 등록해 주는 기능

=> 설정 클래스에 빈으로 직접 등록하지 않아도 원하는 클래스를 빈으로 등록할 수 있다.

 

@ComponentScan

 

컴포넌트 스캐닝을 수행한다.

 

👆 컴포넌트 스캐닝

- 현재 실행 중인 설정 클래스가 속한 패키지와 그 하위 패키지에서 컴포넌트들을 스캐닝한다.

- 컴포넌트는 @Component, @Controller, @Service, @Repository 등의 스프링 관련 애노테이션이 부여된 클래스를 의미한다.

👆 자동 빈 등록

- 컴포넌트 스캐닝을 통해 찾아진 클래스들은 자동으로 스프링 빈으로 등록된다.

- 개발자는 빈 등록에 대한 명시적인 설정을 줄일 수 있다.

👆 패키지 및 필터링 설정

- 스캐닝할 패키지를 지정할 수 있으며, includeFilters와 excludeFilters를 통해 특정 조건에 따라 스캐닝할 클래스를 필터링할 수도 있다.

- 스캐닝 범위를 세밀하게 제어할 수 있다.

👆 다중 @ComponentScan

- 여러 개의 @ComponentScan 애노테이션을 사용하여 다른 패키지를 대상으로 스캐닝할 수 있다.

- 여러 패키지에 걸쳐 있는 컴포넌트들을 한 번에 등록할 수 있습니다.

 

 

🤔 스프링은 자동으로 등록될 Bean을 어떻게 찾을까?

Stereotype 애노테이션을 이용해서 찾는다.

 

Stereotype

 

- 스프링 프레임워크에서 제공하는 애노테이션들의 그룹으로, 특정한 의미와 역할을 가진 애노테이션들을 지칭한다.

- 컴포넌트 스캔(ComponentScan)과 함께 사용되어 특정 애노테이션이 붙은 클래스들을 스캔하여 스프링 빈으로 등록하는 작업을 수행한다.

https://incheol-jung.gitbook.io/docs/q-and-a/spring/stereo-type

 

👆 @Component

해당 클래스를 스프링 빈으로 등록한다.

 

📢 @Bean와 @Component의 차이점

@Component
- 클래스 상단에 적으며, default로 클래스 이름이 Bean의 이름이 된다.
- 스프링에서 @ComponentScan을 사용해서 자동으로 찾아주고 관리해 준다.

@Bean
- @Configuration으로 선언된 클래스 내에 있는 메서드를 정의할 때 사용한다.
- 이 메서드가 반환하는 객체가 Bean이 되며, default로 메서드 이름이 Bean의 이름이 된다.

 

👆 @Configuration

- 한 개 이상의 @Bean 애노테이션으로 정의한 bean 들을 생성하려 할 때 클래스에 정의하는 어노테이션

- 설정 클래스를 나타내는 애노테이션으로 스프링 빈을 정의하고 설정 정보를 제공한다.

 

👆 @Repository

- 데이터베이스와의 상호작용을 담당하는 리포지토리(데이터 접근 계층) 클래스를 나타내는 애노테이션

- 데이터베이스 CRUD 작업이나 데이터 조작과 관련된 로직을 구현하는 데 사용된다.

 

👆 @Service

- 비즈니스 로직을 처리하는 서비스 클래스를 나타내는 애노테이션

- 주로 컨트롤러와 리포지토리 사이에서 데이터 조작이나 비즈니스 규칙을 구현하는 데 사용된다.

 

👆 @Controller

- 웹 애플리케이션에서 컨트롤러 역할을 수행하는 클래스를 나타내는 애노테이션

- MVC 아키텍처에서 사용되며, 클라이언트의 요청을 처리하고 적절한 응답을 반환하는 역할을 담당합니다

---

3. Component Scan 실습

 

Repository 구현체 만들기

 

@Repository
public class MemoryVoucherRepository implements VoucherRepository {
    private final Map<UUID, Voucher> storage = new ConcurrentHashMap<>();

    @Override
    public Voucher insert(Voucher voucher) {
        storage.put(voucher.getVoucherId(), voucher);
        return voucher;
    }
}

@Repository 애노테이션을 통해서 VoucherRespository의 구현체인 MemoryVoucherRepository를 스캔할 수 있도록 한다.

 

🤔 interface인 VoucherRepository에는 안 붙여도 되나?

 

붙여도 되고 안 붙여도 되지만 보통의 경우 구현체에만 붙인다.

 

Spring은 @Repository 애노테이션이 붙은 클래스를 스캔하여 Repository 인터페이스와 매핑하는 방식으로 동작한다.

=> MemoryVoucherRepository를 VoucherRepository 인터페이스의 빈으로 등록

 

+) interface인 VoucherRepository에만 @Repository 애노테이션을 붙이면 구현체를 Bean으로 등록하거나 관리할 수 없다.

 

💡  ConcurrentHashmap이란?

Hashtable 클래스의 단점을 보완하면서 Multi-Thread 환경에서 사용할 수 있도록 나온 클래스

- Thread-Safe 하다
- 어떤 Entry를 조작하는 경우에 해당 Entry에 대해서만 락을 건다.
- HashTable보다 데이터를 다루는 속도가 빠르다.

=> Entry 아이템별로 락을 걸어 멀티 스레드 환경에서의 성능을 향상시킨다.

동작원리가 궁금하다면 추가로 보면 좋을 듯!
[Java] ConcurrentHashMap는 어떻게 Thread-safe 한가?

 

Service에서 Repository 의존성 주입받기

 

@Service
public class VoucherService {
    private final VoucherRepository voucherRepository;

    public VoucherService(VoucherRepository voucherRepository) {
        this.voucherRepository = voucherRepository;
    }
}

VoucherService에서 생성자를 통한 의존성 주입을 통해 스프링은 자동으로 MemoryVoucherRepository 빈을 주입하여 사용한다.

+) MemoryVoucherRepository 클래스가 VoucherRepository 인터페이스를 구현하고 있으며 @Repository 애노테이션이 붙어있기 때문에, 해당 클래스의 인스턴스가 VoucherRepository 타입의 빈으로 등록되어 있으면 주입된다.

 

🤔VoucherRepository의 구현체가 여러 개인 경우에는 어떻게 동작할까?

 

1. @Qualifier을 사용한 명시적인 빈 주입

 

@Service
public class VoucherService {
    private final VoucherRepository voucherRepository;

    @Autowired
    public VoucherService(@Qualifier("memoryVoucherRepository") VoucherRepository voucherRepository) {
        this.voucherRepository = voucherRepository;
    }

    // ...
}

VoucherService 클래스의 생성자에 @Qualifier 애노테이션을 사용하여 "memoryVoucherRepository"라는 이름의 빈을 주입하도록 명시적으로 지정하고 있다. 스프링은 해당 이름을 가진 빈을 찾아서 주입한다.

 

2. @Primary를 사용한 우선적인 빈 주입

 

@Repository
@Primary
public class MemoryVoucherRepository implements VoucherRepository {
    // ...
}

@Primary 애노테이션을 사용하여 MemoryVoucherRepository 클래스를 주 용도로 사용하는 기본 빈으로 지정하고 있다.

VoucherService 클래스에서 VoucherRepository를 주입받을 때 명시적으로 어떤 빈을 주입할지 지정하지 않았다면, 스프링은 @Primary 애노테이션이 붙은 MemoryVoucherRepository 빈을 우선적으로 주입한다.

+) 반드시 하나의 빈에만 적용해야 한다. 

 

💡@Qualifier와 @Primary의 우선순위

1. @Qualifier로 명시한 빈이 우선적으로 주입된다.
2. @Qualifier로 명시한 빈이 없는 경우, @Primary 애노테이션이 붙은 빈이 주입된다.
3. @Qualifier로 명시한 빈이 없고, @Primary 애노테이션이 붙은 빈도 없는 경우에는 NoSuchBeanDefinitionException 예외가 발생합니다.

 

ComponentScan시 특정 패키지 지정하기

 

1. @ComponentScan(basePackages = {})

 

패키지의 이름을 직접 지정하는 방법

 

문자열 배열을 전달하여 스캔한 패키지를 명시한다.

@ComponentScan(basePackages = {"org.prgms.kdt.springorder.order", "org.prgms.kdt.springorder.voucher"})

설정 파일과 같은 패키지에 있어도 해당 배열에 포함되지 않으면 스캔하지 않는다.

 

2. @ComponentScan(basePackageClasses = {})

 

클래스를 기준으로 패키지를 지정하는 방법

 

클래스 배열을 전달하여, 해당 클래스가 존재하는 패키지가 스캔 대상이 된다.

@ComponentScan(basePackageClasses = {Order.class, Voucher.class})

Order.class와 Voucher.class가 있는 패키지만 스캔한다.

 

💡excludeFilters, includeFilters

excludeFilters
스캔 대상에서 제외할 필터를 지정한다.
즉, 해당 필터의 조건을 만족하는 컴포넌트는 스캔 대상에서 제외됩니다.

includeFilters
스캔 대상에 포함할 필터를 지정한다.
즉, 해당 필터의 조건을 만족하는 컴포넌트만 스캔 대상으로 포함된다.

📌 FilterType 종류

FilterType.ANNOTATION: 특정 애노테이션이 적용된 클래스를 대상으로 한다.
FilterType.ASSIGNABLE_TYPE:  특정 클래스나 인터페이스를 상속하거나 구현한 클래스를 대상으로 한다.
FilterType.REGEX: 정규식 패턴과 일치하는 클래스 이름을 가지고 있는 컴포넌트를 대상으로 한다.
FilterType.ASPECTJ: AspectJ 패턴과 일치하는 클래스를 대상으로 한다.
FilterType.CUSTOM: 커스텀 필터를 사용하여 스캔 대상을 제어한다. 커스텀 필터는 TypeFilter 인터페이스를 구현해야 하며, match() 메서드를 통해 조건을 정의한다.

---

4. Autowired

 

SpringBoot 1-2에서 잠깐 다뤘던 DI 종류들이다.

예시를 들어 좀 더 자세히 살펴보자.

 

DI 종류

 

👆 생성자 주입 (Constructor Injection)

 

객체의 생성자를 통해 의존성을 주입하는 방식

객체의 생성 시점에 필요한 의존성을 외부에서 전달받아 사용한다.

 

private final VoucherRepository voucherRepository;

public VoucherService(VoucherRepository voucherRepository) {
    this.voucherRepository = voucherRepository;
}

생성자가 하나인 경우에만 자동으로 @Autowired가 붙는다.

 

👆 setter 주입(Setter Injection)

 

객체의 setter 메서드를 통해 의존성을 주입하는 방식

의존성을 설정하기 위해 setter 메서드를 호출하여 외부에서 의존성을 주입한다.

 

private VoucherRepository voucherRepository;

@Autowired
public void setVoucherRepository(VoucherRepository voucherRepository) {
    this.voucherRepository = voucherRepository;
}

 

👆 필드 주입(Field Injection)

 

의존성을 클래스의 멤버 필드로 직접 주입하는 방식

주로 @Autowired 어노테이션을 사용하여 필드에 자동으로 의존성을 주입한다.

 

private VoucherRepository voucherRepository;

@Autowired
private VoucherRepository voucherRepository;

 

🤔 생성자 주입 방식을 사용하는데 생성자가 2개면 어떻게 해야 할까?

 

두 생성자 중 DI를 하는 생성자에 @Autowired 애노테이션을 달아서 명시적으로 의존성을 주입한다.

 

어떤 DI 방법을 선택해야 할까?

 

https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-collaborators.html#beans-setter-injection

스프링 공식 문서에 생성자 주입 방식을 권장한다고 쓰여있다.

그 이유가 무엇일까?

 

👆 단위 테스트하기에 용이하다.

의존성을 외부에서 주입받기 때문에 단위 테스트에서 모의 객체(Mock Object)를 사용하여 의존성을 주입하는 것이 쉽다.

 

또한 다른 주입 방식은 순수 자바 코드로 단위 테스트를 작성하는 것이 힘들다.

테스트코드는 Spring 위에서 동작하지 않으므로 의존 관계 주입이 발생하지 않아서 NPE(Null Pointer Exception)를 발생한다.

 

👆 불변성을 확보한다.

의존성이 주입된 객체는 변경할 수 없는 불변 객체로 만들 수 있다.

의존성은 객체가 생성될 때 주입되며, 이후에는 변경할 수 없다.

이는 객체의 안정성과 예측 가능성을 높여준다.

 

👆순환 참조를 방지한다.

순환 참조를 런타임 시점에 감지하고 예외를 발생시켜 문제를 해결할 수 있다.

 

생성자 주입은 객체를 생성하는 시점에 의존성을 주입하고 다른 방법은 객체를 생성한 후 의존성을 주입한다.

따라서 생성자 주입은 객체를 생성하는 시점에서 문제를 탐지할 수 있고 나머지 방법은 실제 객체를 사용하거나 실행할 때 문제를 알 수 있다.

 

👆개발자의 의존성 주입 실수 방지 (final 키워드의 사용)

구현체 주입에 대한 코드를 잊어버리고 적지 않아도 컴파일 시점에서 누락된 의존성을 확인할 수 있다.

---

5. Beans Scope

 

https://docs.spring.io/spring-framework/reference/core/beans/factory-scopes.html

 

 

스프링 프레임워크에서는 기본적으로 싱글톤(Singleton)과 프로토타입(Prototype) 두 가지 스코프를 지원한다.

그 이유는 이 두 가지 스코프가 대부분의 상황에서 요구사항을 충족시킬 수 있기 때문이다.

👆 싱글톤 스코프

하나의 빈 인스턴스를 스프링 컨테이너 당 하나만 생성하여 관리한다.

따라서 동일한 빈을 요청할 때마다 항상 동일한 인스턴스가 반환된다.

싱글톤은 기본 스코프로 설정되어 있으며, 많은 경우에 메모리 효율성과 성능 향상을 위해 싱글톤 스코프를 사용하는 것이 권장된다.

👆 프로토타입 스코프

요청할 때마다 새로운 빈 인스턴스를 생성한다.

매번 요청할 때마다 새로운 인스턴스를 반환하기 때문에 동일한 타입의 빈을 여러 개 생성하고 사용해야 할 때 유용합니다.

예를 들어, 각각의 요청에 대해 별도의 상태를 유지해야 하는 경우에 프로토타입 스코프를 사용할 수 있다.

 

빈 스코프를 변경하는 방법

 

해당 빈의 클래스나 구성 파일에 @Scope 애노테이션을 추가하고 원하는 스코프 값을 설정하면 된다. 

@Scope(value = ConfigurableBeanFactory.SCOPE_SINGLETON)  // default
@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)

---

6. Lifes Cycle

 

Spring Application Context는 객체의 생성과 소멸, 즉 생명주기(Life Cycle)를 관리한다.

applicationContext.close();

close()를 사용하면 applicationContext가 소멸되며, 컨테이너에 등록된 모든 빈도 함께 소멸된다.

이 과정에 소멸에 대한 callback이 동작한다.

 

Bean 생성 생명주기 콜백

 

1. @PostConstruct 애노테이션이 적용된 메서드 호출

@PostConstruct
public void postConstruct() {}

2. Bean이 InitializingBean 인터페이스 구현시 afterPropertiesSet() 호출

@Repository
public class MemoryVoucherRepository implements VoucherRepository, InitializingBean {
    @Override
    public void afterPropertiesSet() throws Exception {}
}

 

3. @Bean 애노테이션의 initMethod에 설정한 메소드 호출

public class AppConfiguration {
    @Bean(initMethod = "init")
    public BeanOne beanOne() {

    class BeanOne {
        private void init() {}
    }
}

 

Bean 소멸 생명주기 콜백

 

1. @PreDestory 애노테이션이 적용된 메소드 호출

@Override
public void destroy() throws Exception {}

 

2. Bean이 DisposableBean 인터페이스 구현시 destroy() 호출

@Repository
public class MemoryVoucherRepository implements VoucherRepository, DisposableBean {
    @PreDestroy
    public void preDestroy() {}
}

 

3. @Bean 애노테이션의 destroyMethod에 설정한 메소드 호출

public class AppConfiguration {
    @Bean(initMethod = "destroy")
    public BeanOne beanOne() {

    class BeanOne {
        private void destroy() {}
    }
}

 

Reference

Circular Dependencies in Spring

HashMap vs HashTable vs ConcurrentHashMap

Spring @ComponentScan - 필터 유형

[Spring] 생성자 주입을 사용해야 하는 이유

[Spring] 다양한 의존성 주입 방법과 생성자 주입을 사용해야 하는 이유 - (2/2)