Bean의 생명주기 콜백 🌱

스프링 빈의 생명주기

[객체 생성 -> 의존관계 주입]

대부분 스프링 빈은 위와 같이 라이프사이클을 가집니다. 스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료됩니다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 합니다.

 

스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공합니다. 싱글톤을 사용 시스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 줍니다.  따라서 안전하게 종료 작업을 진행할 수 있습니다. 

 

스프링 빈의 이벤트 라이프 사이클은??

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

 

스프링 빈의 이벤트 라이프사이클을 보자면, 스프링 컨테이너를 생성하고 스프링 빈을 생성합니다. 이때 생성자 주입일 경우 어느정도 이 단계에서 생겨납니다. 다음으로 의존관계를 주입해줍니다. 이 단계에서 setter 주입과 필드 주입이 일어납니다. 초기화 콜백은 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출합니다.  빈을 모두 사용하고 소멸 전에 콜백을 호출하고 종료하는 사이클을 가지고 있습니다. 

전에 아래와 같은 글을 작성했습니다.

---

https://applepick.tistory.com/130

의존관계 주입시 생성자 주입을 사용하자! 😲

 

위에 제가 정리한 글을 잠깐 보면 의존관계 주입 시 4가지의 방법이 있다고 말씀드렸습니다. 생성자 주입이 절대적으로 모든 상황에서 좋은 방법은 아닙니다. 

 

객체의 생성과 초기화는 분리하자!

생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가집니다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는등 무거운 동작을 수행합니다. 따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것보다는 객체를 생성하는 부분과 초기화하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋습니다. 이때는 setter 주입이 좋습니다.  물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는 게 더 나을 수 있다. 이때는 생성자 주입이 좋습니다. 정리하면서 상황과 확장성을 고려해서 설계하는 것이 중요하다고 느꼈습니다.