스프링 빈 생명주기

스프링 빈에게도 LifeCycle(생명주기)가 존재한다.

 

이번 포스팅은 그 생명주기를 살펴볼 것이다.

 

 

 

생명주기를 살펴보기위해, 각 구간마다 로그를 남겻다.

 

1.빈을 생성할때  [NetworkClient() 메소드] 

 

2. 서비스(빈)가 시작할때 먼저 부르고싶을때 [ connect() 메소드 ]

 

3. 서비스(빈)가 기능할때 [ call() 메소드]

 

4. 서비스(빈) 종료시 수행하고 싶을때 [ disconnect() 메소드 ]

 

 

스프링 컨테이너를 생성한뒤,   스프링컨테이너를 닫아보겠다.

 

NetworkClient를 수동등록을 하였는데,  주목해야할 부분은

 

initMethod 와 destoryMethod 이다.

 

initMethod는 빈의 생성자가 모두 생성된후 호출하고싶을때 사용한다.

 

destoryMethod는 빈이 종료되기 직전에 호출하고 싶을때 사용한다. 

 

우선 실행을시켜서 실행결과를 살펴보자.

 

결과다. 여기서 우리는 생명주기를 엿볼수있다.

 

 

1. NetworkClient의 빈 생성

 

2. NetworkClient 생성자 호출 

->null인 이유는, setURL을 아직 받지못했기때문이다.

 

3.init() 메소드 호출 

-> connect()가 호출되었다.

-->call() 호출

 

4.close() 메소드 호출

 

 

요약하자면

 

빈 생성 -> 초기화 -> 사용 -> 소멸  순으로 진행된다.

 

 

------------------------------------------------------------------------------------------------

 

 

initMethod 와 destoryMethod 말고

 

더 좋은 방법도 존재한다.

 

 

바로 @PreConstruct 와 @PreDestroy 이다.

 

 

스프링에서도 권장하는 방식이다.

 

우선 애노테이션을 보면 알겠지만, 해석해보면 무슨 기능인지 의미가 확 와닿는다.

 

->@PostConstruct.. 음 생성자 다음에 호출되는놈이군!

->@PreDestroy 아하 파괴되기전에 호출되는 놈이군!

 

그리고 이렇게 자동완성 애노테이션을 하는게 더 편리하고 간편하다.

 

이전에 @Bean( initMethod , destoryMethod)같은경우는 내가 일일이 해당 메소드 이름을 작성해야되서

번거롭기때문이다.

 

하지만 요것도 유일한 단점이 존재하는데, 코드 수정이 불가능한

외부 라이브러리에 존재하는 초기화, 종료메소드를 가져오지 못한다.

 

-> 이게 무슨소리냐면, 외부 라이브러리는 이미 컴파일이 된상태로 오기때문에

코드수정이 불가능하다. 즉 @PostConstruct,@PreDestroy를  못붙힌다.

 

 

다음과 같은 상황일경우 @Bean( initMethod , destoryMethod)를 사용하면된다.

 

이것 이외에는 @PostConstruct, @PreDestroy를 사용하는것을 권장한다.