일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 외부키
- WeNews
- EC2
- querydsl
- 테스트메소드
- ubuntu
- 네이티브쿼리
- docker명령어
- 적용우선순위
- appspec.yml
- 추후정리
- 검색
- 메세지수정
- subquery
- 포트
- foreignkey
- appspec
- 테스트
- 참조키
- 예약
- AuthenticationEntryPoint
- 커밋메세지수정
- Query
- 서브쿼리
- 컨테이너실행
- 2 > /dev/null
- ㅔㄴ션
- application.yml
- MySQL
- 메소드명
- Today
- Total
제뉴어리의 모든것
[스프링 핵심 원리] 빈 생명주기 콜백 본문
빈 생명주기 콜백 메소드
빈이 생성되고 속성들을 초기화 해야하는 경우가 있다.
그리고 빈 소멸시에 속성들을 정리(DB Connection 끊기와 같은) 해줘야 하는 경우도 있다.
이런 경우에 개발자는 빈의 생성 시점과 소멸시점을 인지할 수 있는 방법이 없다.
이럴때 스프링은 여러가지 방법으로 초기화 시점과 소멸 시점을 알려준다.
그 방법들을 설명하려 한다.
+ 스프링 빈의 이벤트 라이프사이클
스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 사용 -> 소멸전 콜백 -> 스프링 종료
- 초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
- 소멸전 콜백: 빈이 소멸되기 직전에 호출
한가지 의문
그냥 빈의 생성자에 초기화 부분을 다 넣어주면 되지 않을까?
그것도 한가지 방법일 수는 있다.
그렇지만, 초기화 해야하는 속성들이 많거나
모든 빈들이 생성되고 나서 속성을 세팅해야 하는 경우 등등 여러가지 경우가 있을 것이다.
그러나 기본적인 객체 지향 프로그래밍은
생성자는 생성자의 역할만을 하고, 초기화 메소드는 초기화 역할만을 수행하는것이다.
그래야지 유지보수의 경우에도 용이하다.
빈 생명주기 콜백의 종류
- 1. 인터페이스(InitializingBean, DisposableBean)
현재는 잘 사용하지 않는 방법이다.
왜냐하면 스프링에 너무 의존적이기 때문이다. - 설정 정보에 초기화 메서드, 종료 메서드 지정
- @PostConstruct, @PreDestroy 애노테이션 지원
가장 추천되는 방식이며 기본적으로 사용되는 방법이다.
상황에 따라 두번째 방법과 겸용하여 사용된다.
1. 인터페이스 InitializingBean, DisposableBean
- 사용 코드
package hello.core.lifecycle;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
public class NetworkClient implements InitializingBean, DisposableBean { //인터페이스 implemtens
private String url;
public NetworkClient() {
System.out.println("생성자 호출, url = " + url);
}
public void setUrl(String url) {
this.url = url;
}
//서비스 시작시 호출
public void connect() {
System.out.println("connect: " + url);
}
public void call(String message) {
System.out.println("call: " + url + " message = " + message);
}
//서비스 종료시 호출
public void disConnect() {
System.out.println("close + " + url);
}
@Override
public void afterPropertiesSet() throws Exception { //초기화 메소드 구현
connect();
call("초기화 연결 메시지");
}
@Override
public void destroy() throws Exception { //소멸자 메소드 구현
disConnect();
}
}
- 적용 방법
1. InitializingBean, DisposableBean 인터페이스를 빈으로 등록될 클래스에 구현한다
2. InitializingBean, DisposableBean 을 구현하여 재정의 해야하는 메소드
afterPropertiesSet, destroy 를 구현한다. - 초기화, 소멸 인터페이스 단점
- 이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
- 초기화, 소멸 메서드의 이름을 변경할 수 없다.
- 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.
만약 개발 중에 외부 라이브러리를 가져와서 사용해야 하는데, 해당 라이브러리의 클래스를 빈으로 등록해야 하는 경우가 있다. 이 경우 해당 라이브러리의 코드를 내가 직접 수정할 수 없는 경우라면 해당 방법은 사용할 수가 없다.
2. 빈 등록 초기화, 소멸 메서드 지정
설정 정보에 @Bean(initMethod = "init", destroyMethod = "close") 처럼 초기화, 소멸 메서드를 지정할 수 있다.
- 빈으로 등록할 클래스
package hello.core.lifecycle;
public class NetworkClient {
private String url;
public NetworkClient() {
System.out.println("생성자 호출, url = " + url);
}
public void setUrl(String url) {
this.url = url;
}
//서비스 시작시 호출
public void connect() {
System.out.println("connect: " + url);
}
public void call(String message) {
System.out.println("call: " + url + " message = " + message);
}
//서비스 종료시 호출
public void disConnect() {
System.out.println("close + " + url);
}
public void init() { //초기화 메소드를 정의
System.out.println("NetworkClient.init");
connect();
call("초기화 연결 메시지");
}
public void close() { //소멸자 메소드를 정의
System.out.println("NetworkClient.close");
disConnect();
}
}
- 초기화, 소멸자 메소드 지정
@Configuration
static class LifeCycleConfig {
@Bean(initMethod = "init", destroyMethod = "close") // 클래스에 정의된 초기화, 소멸자 메소드 지정
public NetworkClient networkClient() {
NetworkClient networkClient = new NetworkClient();
networkClient.setUrl("http://hello-spring.dev");
return networkClient;
}
}
- 설정 정보 사용 특징
- 메서드 이름을 자유롭게 줄 수 있다.
- 스프링 빈이 스프링 코드에 의존하지 않는다.
- 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다. (최고의 장점이다)
+ 종료 메서드 추론
@Bean의 destroyMethod 속성에는 아주 특별한 기능이 있다.
- 라이브러리는 대부분 close , shutdown 이라는 이름의 종료 메서드를 사용한다.
- @Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다.
- 이 추론 기능은 close , shutdown 라는 이름의 메서드를 자동으로 호출해준다.
- 이름 그대로 종료 메서드를 추론해서 호출해준다. 따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다. 추론 기능을 사용하기 싫으면 destroyMethod="" 처럼 빈 공백을 지정하면 된다.
애노테이션 @PostConstruct, @PreDestroy
초기화 메소드로 지정할 메소드와 소멸자 메소드로 지정할 메소드에 해당 애노테이션들을 붙이는 방법이다.
코드를 보자.
package hello.core.lifecycle;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
public class NetworkClient {
private String url;
public NetworkClient() {
System.out.println("생성자 호출, url = " + url);
}
public void setUrl(String url) {
this.url = url;
}
//서비스 시작시 호출
public void connect() {
System.out.println("connect: " + url);
}
public void call(String message) {
System.out.println("call: " + url + " message = " + message);
}
//서비스 종료시 호출
public void disConnect() {
System.out.println("close + " + url);
}
@PostConstruct //초기화 메소드 지정
public void init() {
System.out.println("NetworkClient.init");
connect();
call("초기화 연결 메시지");
}
@PreDestroy //소멸자 메소드 지정
public void close() {
System.out.println("NetworkClient.close");
disConnect();
}
}
@Configuration
static class LifeCycleConfig {
@Bean
public NetworkClient networkClient() {
NetworkClient networkClient = new NetworkClient();
networkClient.setUrl("http://hello-spring.dev");
return networkClient;
}
}
- @PostConstruct, @PreDestroy 애노테이션 특징
- 최신 스프링에서 가장 권장하는 방법이다.
- 애노테이션 하나만 붙이면 되므로 매우 편리하다.
- 패키지를 잘 보면 javax.annotation.PostConstruct 이다. 스프링에 종속적인 기술이 아니라 JSR-250 라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다. 컴포넌트 스캔과 잘 어울린다.
- 유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료 해야 하면 @Bean의 기능을 사용하자
외부 라이브러리를 사용하면서 라이브러리에서 제공되는 클래스의 초기화, 소멸자 메소드를 지정하고 싶을때는 사용하지 못한다. 왜냐하면 해당 라이브러리의 코드에 내가 직접 메소드를 작성하고 @PostConstruct, @PreDestroy 애노테이션을 달아야 하기 때문이다.
이 경우에는 앞서 설명한 두번째 방법을 사용하자.
결론
기본적으로 @PostConstruct, @PreDestroy 방법을 사용하지만, 외부 라이브러리 사용시와 같은 예외사항에서는
@Bean(initMethod = "init", destroyMethod = "close") 방식을 사용하자.
'Spring Boot > 스프링 핵심 원리' 카테고리의 다른 글
[스프링 핵심 원리] 컴포넌트 스캔 (0) | 2022.08.13 |
---|---|
[스프링 핵심 원리] 싱글톤 컨테이너 (0) | 2022.08.10 |
[스프링 핵심 원리] 스프링 컨테이너와 스프링 빈 (0) | 2022.08.08 |
[스프링 핵심 원리] 객체 지향 설계와 스프링 ~ 스프링 핵심 원리 이해2 - 객체 지향 원리 적용 (0) | 2022.08.07 |