빈 생명주기 콜백 개념

• DB connection pool이나 네트워크 소켓처럼 어플리케이션 시작 시점에 필요한 연결을 뭐 대강 10개면 10개 100개면 100개를 미리 해두고,
  왜냐하면 [TCP/IP 핸드쉐이킹](https://velog.io/@jeong_woo/TCP-UDP)하고 연결하는데 조금 시간이 걸리기 때문이고 또 연결해둔 걸 돌아가며 고객에게 제공하기 때문이다.
  어플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

• 간단하게 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정해보자, 실제로 네트워크에 연결하는 것은 아니고, 단순히 문자만 출력하도록 했다. 이 NetworkClient는 어플리케이션 시작 시점에 connect()를 호출해서 연결을 맺어두어야하고, 어플리케이션이 종료되면 disconnect()를 호출해서 연결을 끊어야한다.

• 자, 그럼 우선 코드를 봐보자.

public class NetworkClient {
    private String url;
    public NetworkClient(){
        System.out.println("생성자 호출, url = " + url);
        connect();
        call("초기화 연결 메시지입니다.");
    }

    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);
    }
}

• 위와같은 class가 있다고 가정하고

public class BeanLifeCycleTest {
    @Test
    public void lifeCycleTest() {
        // 이때 보통은 ApplicationContext을 썼는데 이 .close() 메서드가 흔히 제공되는 건 아니기 때문에 ConfigurableApplicationContext로 해줘야한다.
        ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        NetworkClient client = ac.getBean(NetworkClient.class);
        ac.close();
    }

    @Configuration
    static class LifeCycleConfig {

        @Bean
        public NetworkClient networkClient() {
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("https://hello-spring.com");
            return networkClient;
        }
    }

}

• 위와같은 테스트 코드를 작성한다고 가정했을 때 결과는 아래와 같다.

• 왜 null일까? -> 당연하다. setUrl 자체를 객체 생성이 완료된 후에 넣었기 때문에 객체가 생성되는 시점에서는 모두 null로 뜨는게 정상이다.
  하지만! 현업에서는 중간에 값이 setting되는 일이 허다하다.
  또 당장 자동 의존성 관계 주입에서만 봐도 setter나 field injection이 가능하다. 그럼 이 spring에서는 어떻게 이를 가능하게 할까?

스프링 빈의 라이프 사이클

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

• 물론 생성자 주입은 예외고 나머지 주입방법(setter, field injection)은 당연히 객체가 생성이 되야 의존관계를 주입할 수 있다.

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

• 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점(의존관계 주입이 끝났으니 초기화를 해!)을 알려주는 3가지 기능을 제공한다. 또, 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다.

스프링 빈의 이벤트 라이프 사이클 (싱글톤)

• 스프링 컨테이너 생성 -> 스프링 빈 생성(생성자 주입) -> 의존관계 주입(setter, field 주입) -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료
• 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후
  소멸전 콜백 : 빈이 소멸되기 직전에 호출

아니 그럼 다 생성자 주입으로 하면 되는거 아닌가?

-> 객체의 생성과 초기화를 분리하자! (단일책임원칙과 비슷)

• 생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 갖는다.
  반면, 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.

• 따라서 생성자 안에서 무건운 초기화 작업을 함께 하는 것 보다는 객체를 생성하는 부분과 초기화하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다.
  물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 더 나을 수 있다.

• 또 다른 장점으로는 객체를 생성하고 실제 외부와 connec하는 것은 최초의 어떤 메서드에 의해서 호출될 때 까지 대기할 수도 있는 부분이다.
  그럼 그때 초기화를 호출하여 동작을 지연시킬 수 있는 장점도 갖고있다.

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

1. 인터페이스 (InitalizingBean, DisposableBean)

public class NetworkClient implements InitializingBean, DisposableBean {

• 이렇게 class 끝에 InitalizingBean 인터페이스를 구체화하면

@Override
public void afterPropertiesSet() throws Exception {
  connect();
  call("초기화 연결 메시지입니다.");
}

@Override
public void destroy() throws Exception {
  disConnect();
}

• 이런 메서드를 볼 수 있는데,
  afterPropertiesSet는 이름 그대로 프로퍼티들이 세팅이 끝나면(의존관계 주입이 끝나면) 이 메서드의 기능을 실행한다 라는 뜻이다.
  destroy 역시 직관적으로 Bean이 소멸될 때 실행되는 메서드라는 뜻이다.

• 당연히 객체가 생성될 때는 값이 안 들어있기에 null이지만
  객체가 생성이 되고 외부에서 호출될 때 (상단 test code에서 networkClient.setUrl("https://hello-spring.com");부분) 비로소 afterPropertiesSet이 동작하여 값들이 null이 아닌 것을 볼 수 있다.

초기화, 소멸 인터페이스의 단점
1. 이 인터페이스는 스프링 전용 인터페이스이다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
2. 초기화, 소멸 메서드의 이름을 변경할 수 없다.
3. 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.
그래서 거의 사용하지 않는다.

2. 설정 정보에 초기화 메서드, 종료 메서드 지정

• 우선 초기화와 소멸될 때 사용할 메서드를 클래스 밑에 선언한다.

public void init() {
  connect();
  call("초기화 연결 메시지입니다.");
}

public void close() {
  disConnect();
}

• 그리고 해당 메서드를 @Bean을 생성하는 곳에 명시해준다.

@Bean(initMethod = "init", destroyMethod = "close")
public NetworkClient networkClient() {
  NetworkClient networkClient = new NetworkClient();
  networkClient.setUrl("https://hello-spring.com");
  return networkClient;
}

특징으로는

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

종료 메서드 추론

• @Bean 으로 등록할 때, destoryMethod 속성에는 아주 특별한 기능이 있다.
• 라이브러리는 대부분 close, shudown이라는 이름의 종료 메서드를 사용한다.
• @Bean의 destoryMethod는 기본값이 "(inferred)"로 등록되어있다.
• 이 추론 기능은 외불 라이브러리들이 보통 close, shutdown 라는 이름을 많이 사용하는데 이 메서드를 자동으로 호출해준다. 이름 그대로 종료 메서드를 추론해서 호출해준다.
  따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 작동한다.
• 애매하게 추론하게끔 하기 싫다면 위 코드처럼 destroyMethod으로 명시해주면 된다.

3. @PostConstruct, @PreDestory 어노테이션 지원 (이거 사용하면 됨.)

@PostConstruct
public void init() {
  connect();
  call("초기화 연결 메시지입니다.");
}

@PreDestroy
public void close() {
  disConnect();
}

• 참고로 보면 jakarata 에서 가져오는 패키지는 Spring 종속기술이 아닌 자바 표준(인터페이스 모음)이기 때문에 스프링이 아닌 다른 컨테이너에서도 동작한다.

• 그리고 어노테이션 하나만 메서드위에 붙이면 되기 때문에 매우 편리하다.
  또 컴포넌트 스캔과도 잘 어울린다.

• 다만 단점으로는 외부 라이브러리에 적용을 못한다.. 그래서 외부 라이브러리를 초기화, 종료 해야한다면 @Bean의 기능(2번)을 사용해야한다.