[spring기본] 8. 빈 생명주기 콜백

빈 생명주기 콜백 시작

• 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 종료 시점에 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

• 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정해보자, 이 NetworkClient는 시작 시점에 connect()를 호출해 연결을 맺어두어야 하고, 애플리케이션이 종료되면 disConnect()를 호출해 연결을 끊어야 한다.

• 테스트 코드를 작성한다. ConfigurableApplicationContext는 AnnotationConfigApplicationContext의 상위 인터페이스다(부모는 자식을 담을 수 있다) 이를 사용하는 이유는 스프링 컨테이너를 종료하는 close()메소드가 이 인터페이스에 존재하기 때문이다.

• 실행을 했는데 url에 널 값이 들어왔다

• url 정보 없이 connect가 호출된 것이다. 당연히 객체를 생성하는 단계에서는 url이 없고, 객체를 생성한 다음에 외부에서 수정자 주입을 통해서 setUrl()이 호출되어야 url이 존재하게 된다.

• 스프링 빈의 라이프사이클은 간단하게 다음과 같다:
  "객체 생성" -> "의존관계 주입"

• 스프링 빈은 객체를 생성하고 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존관계 주입이 모두 완료된 시점을 어떻게 아는가?

• 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메소드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다.

스프링 빈의 이벤트 라이프사이클 :
스프링 컨테이너 생성 - 스프링 빈 생성 - 의존관계 주입 - 초기화 콜백 - 사용 - 소멸전 콜백 - 스프링 종료

• 참고로 객체의 생성과 초기화를 분리하는게 좋다. 초기화 로직까지 객체 생성자에 넣지 말란 얘기다. 생성자는 말 그대로 객체를 생성하는 데에만 집중해라, 생성자는 필수정보(파라미터)를 받고 메모리를 할당해 객체를 생성하는 책임을 가지는 반면, 초기화는 생성된 값을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.

• 따라서 생성자 안에서 무거운 초기화 작업을 하지 말고 두 부분을 명확하게 나누는 것이 유지보수하기 좋다.

• 스프링은 크게 3가지 방법으로 빈 생명주기 콜백을 지원한다

1. 인터페이스
2. 설정 정보에 초기화 메소드, 종료 메소드를 지정
3. @PostConstruct, @PreDestroy 어노테이션 지원

인터페이스

• 만들었던 NetworkClient에서 InitializingBean을 상속하자, 이것이 초기화용 빈이다.
• 프로퍼티들이 세팅완료되면, 즉 의존관계 주입이 끝나면 호출되는 afterPropertiesSet()을 오버라이딩 해 연결이 수행되도록 한다.
• 또 DisposableBean을 상속해 destroy()를 오버라이딩해 종료 시점에 disconnect를 호출하도록 한다.
• 스프링 컨테이너가 의존관계 주입이 완료되면 afterPropertiesSet(), 프로그램이 종료되면 destroy() 를 호출한다.

• 테스트를 돌려보면 의존관계 주입이 끝난 후 connect가 호출되어 url 값이 초기화되었다.

• 또 종료 시점에 destroy가 호출된 것도 확인 가능(Closing~)하다.

• 그러나 초기화, 소멸 인터페이스의 단점이 있다. 이는 스프링 전용 인터페이스이므로 내 코드가 스프링 전용 인터페이스에 의존한다.

• 초기화, 소멸 메소드의 이름을 변경할 수 없다.

• 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

• 그래서 인터페이스로 초기화, 종료하는 방법은 잘 쓰지 않는다.

빈 등록 초기화, 소멸 메소드

• 설정 정보에 @Bean(initMethod = "init", destroyMethod = "close") 처럼 초기화, 소멸 메서드를 지정할 수 있다.

• 인터페이스를 빼고 기존 메소드를 수정하자

• Bean에서 initMethod = "init", destroyMethod = "close" 를 지정하고 호출한다.

• 정상적으로 초기화, 소멸 메소드가 동작한다.

설정 정보 사용의 특징 :
1. 메소드 이름을 자유롭게 줄 수 있다.
2. 스프링 빈이 스프링 코드에 의존하지 않는다
3. 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메소드를 적용할 수 있다.

종료 메소드 추론

• @Bean 의 destroyMethod 속성에는 대단한 기능이 있다.
  
• destroyMethod를 까보면 디폴트 값이 INFER_METHOD 로 지정되어 있다.
• 이는 close, shutdown이라는 이름의 메소드를 자옹으로 호출해준다. 그래서 "추론(infer)"인 것이다.
• 따라서 직접 스프링 빈으로 등록하면 종료 메소드를 따로 적지 않아도 알아서 호출한다.
• 추론 기능을 쓰기 싫으면 destroyMethod = "" 라고 쓰면 된다

애노테이션 @PostConstruct, @PreDestroy

• 결론부터 말하면 세 방법 중 이 방법을 쓰면 된다.
• 이름만 봐도 @PostConstruct = 생성 전, @PreDestroy = 소멸 전 이다.

• 그냥 생성과 종료 메소드에 각각 @PostConstruct, @PreDestroy를 붙여주면 끝이다.

• 이는 최신 스프링에서 가장 권장하며 어노테이션 하나만 붙이면 되니 매우 편하다.

• 패키지를 잘 보면 javax.annotation.PostConstruct 이다. 스프링에 종속적인 기술이 아니라 JSR-250 라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.

• 컴포넌트 스캔과 잘 어울린다. 빈 등록 대상이 아니기 때문이다->잘모르겠다

• 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료해야할 경우 @Bean의 initMethod, destroyMethod 기능을 이용하자.