일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- mock
- JPA
- AOP
- CircuitBreaker
- MSA
- 서블릿
- 프로그래머스
- 우아한세미나
- 코드리뷰
- 우테코
- Level2
- 백준
- 스프링 부트
- 의존성
- 우아한테크코스
- 트랜잭션
- JUnit5
- 스프링부트
- HTTP
- 레벨2
- yml
- 프리코스
- REDIS
- Docker
- 자바
- AWS
- 미션
- 세션
- Spring Batch
- Paging
Archives
- Today
- Total
늘
[Spring bean lifecycle, hook]빈 생명주기 본문
728x90
빈이 생성된 이후 추가로 호출되는 콜백들이 있는데요. Spring bean lifecycle, Spring bean hook 같은 키워드로 검색해보시면 도움이 될 것 같아요!
저번에 테스트 격리에 대해 학습하면서 토미가 키워드를 주셨는데, 오늘은 이 키워드를 정리해보려고 한다.
빈 생성
- IoC컨테이너가 만들어진다. -> ComponentScan을 통해 빈으로 등록할 객체들을 찾는다.
- IoC 컨테이너 안에 빈을 등록한다. 그리고 의존관계 주입을 하기 전에 준비 단계가 있다.
- 이 준비 단계에서 객체 생성이 일어난다.
-
- 생성자 주입: 객체의 생성, 의존관계 주입이 동시에 일어남
- setter, Field 주입: 객체의 생성 -> 의존관계 주입으로 라이프 사이클이 나누어져 있음
스프링 의존관계 주입이 완료된 시점
의존관계 완료 시점을 알지 못하면 저번 테스트에서 빈 주입 실패 에러가 나온 것처럼 나올 수 있다. 그렇기 때문에 의존관계 주입이 완료된 시점에 대해서 알아보자
<정리해본 빈의 생성 주기>
스프링 컨테이너 생성 -> 스프링 빈 생성 -> 객체 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료
- 초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
- 소멸전 콜백: 빈이 소멸되기 직전에 호출
@Component
public class BeanTestClass {
@PostConstruct //초기화 메서드
public void initTest() {
System.out.println(" 의존관계 주입이 끝나면 호출해주는 콜백");
}
@PreDestroy //소멸 메서드
public void destoryTest() {
System.out.println("빈 소멸 전 콜백");
}
}
빈 스캔 순서
ComponentScan 와 EnableAutoConfiguration 를 통해서 처음에 빈으로 등록한다.
componentScan → Auto configuration순서로 빈을 등록한다.
- 최상위 디렉토리에서 하위 디렉토리를 찾으면서 @ComponentScan 이 일어난다.(SpringBootApplication 어노테이션에 등록되어 있다.) configuration파일을 찾아서 처음에 @Configuration이 붙은 클래스를 빈으로 등록한다. (@Configuration 내부에는 @Component 가 있다.)
- 빈 이름→ 타입 순서대로 빈을 등록한다.
- componentScan이 완료되면 AutoConfiguration이 작동한다.
- 만약 새로 만든 빈과 AutoConfiguration에서의 빈이 중복될 경우 @ConditionalOnMissingBean 어노테이션을 붙이면 처음 빈이 등록되어있으면 그대로 사용하고 없으면 새로운 빈을 끼운다.
빈 주입시 생성자 주입
- final을 통한 불변으로 만들 수 있다.
- @Autowired를 사용한 스프링에 대한 의존성 생김 방지 등의 장점이 있다.
- 순환참조가 발생한다면 어플리케이션단에서 미리 알려줄 수 있다.
테스트에서는 생성자 주입을 사용하지 않은 이유?
테스트에서는 @Autowired를 안붙여도 의존성 주입하는데 큰 어려움이 없었고, 어차피 @Autowired를 붙여야해서 스프링 종속적인 코드가 된다. 또한 값을 꺼내서 확인하는 등 검증을 위한 Repo와 같이 추가되는 빈이 있어서 양이 커지면서 @Autowired로 간단하게 적용하는게 가시적으로도 좋다.
728x90
'백앤드 개발일지 > 스프링부트' 카테고리의 다른 글
[RestDocs]API 문서화 (2) | 2022.06.03 |
---|---|
@Mock vs @MockBean vs @InjectMocks (1) | 2022.05.31 |
@RestController와 @ResponseBody없이 json으로 통신하는 방법 (2) | 2022.04.30 |
@RequestBody와 @ModelAttribute 차이 (0) | 2022.04.27 |
[Gradle] runtimeOnly와 implementation와 testImplementation의 차이 (0) | 2022.03.31 |
Comments