6. [스프링 핵심 원리 - 기본편] 빈 생명주기 콜백

1. 빈 생명주기 콜백

데이터베이스 커넥션 풀이나, 네트워크 소켓과 같은 것들은 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료할 필요가 있다. 아래의 NetworkClient라는 클래스에서 connect()를 통해 미리 연결을 하고, disconnect()를 통해 연결을 종료한다고 가정해보자.

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
        connect();
        call("초기화 연결 메세지");
    }

    public void setUrl(final 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);
    }
}

 

NetworkClient를 통해 아래와 같은 테스트 코드를 작성하여 실행해보면, url이 모두 null이 나오는 걸 확인할 수 있다. 이는 사실 당연한 결과이다. setUrl을 통해 url을 지정하기 때문에, 객체 생성 시점에는 url이 null이기 때문이다.

class BeanLifeCycleTest {
    @Test
    void lifeCycleTest() {
        ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        final NetworkClient client = ac.getBean(NetworkClient.class);
        ac.close();
    }

    @Configuration
    static class LifeCycleConfig {
        @Bean
        public NetworkClient networkClient() {
            final NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hello.dev");
            return networkClient;
        }
    }
}

 

스프링 빈은 다음과 같은 순서로 생성이 된다.

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존 관계 주입

 

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

스프링은 의존관계 주입이 완료되면, 스프링 빈에게 콜백 메서드를 통해 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링 컨테이너가 종료되기 직전에 대한 소멸 콜백 기능도 제공한다. 따라서 개발자는 이를 이용하여 초기화와 소멸을 구현할 수 있다. 이를 포함한 스프링 빈의 라이프 사이클은 다음과 같다

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

 

* 참고 : 객체의 생성과 초기화를 분리하자.

사실 생성자를 통한 의존 관계 주입을 이용하면, 스프링 빈이 생성되면서 의존 관계도 같이 주입이 되기 때문에, 이 때 초기화를 할 수도 있다. 근데 만약 초기화 작업에 외부 커넥션 연결 등과 같은 무거운 동작이 포함되어 있다면, 생성자가 너무 많은 책임을 가지게 된다. 이는 SRP에 위배되고, 이보다는 객체의 생성과 초기화 부분을 명확하게 분리하는 것이 유지 보수 관점에서 좋다. 물론 내부 값들만 약간 변경하는 단순한 초기화의 경우, 생성자에서 한 번에 처리하는 게 나을 수도 있다.

 

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

1) 인터페이스(InitializingBean, DisposableBean)

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

3) @PostConstruct, @PreDestroy 애노테이션 지원

 

2. 인터페이스(InitializingBean, DisposableBean)

아래와 같이 NetworkClient 클래스가 InitializingBean, DisposableBean 인터페이스를 구현하도록 한 후, afterPropertiesSet()에서 초기화를, destroy()에서 소멸 로직을 넣어주면 된다.

public class NetworkClient implements InitializingBean, DisposableBean {

    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    public void setUrl(final 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() {
        System.out.println("NetworkClient.afterPropertiesSet");
        connect();
        call("초기화 연결 메세지");
    }

    @Override
    public void destroy() {
        System.out.println("NetworkClient.destroy");
        disconnect();
    }
}

class BeanLifeCycleTest {
    @Test
    void lifeCycleTest() {
        ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        final NetworkClient client = ac.getBean(NetworkClient.class);
        ac.close();
    }

    @Configuration
    static class LifeCycleConfig {
        @Bean
        public NetworkClient networkClient() {
            final NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hello.dev");
            return networkClient;
        }
    }
}

 

인터페이스 방식의 단점

1) 이 인터페이스들은 스프링 전용 인터페이스이다. 해당 코드가 스프링 전용 인터페이스에 의존하게 된다. 물론 스프링으로 개발하면서 아예 스프링에 의존적이지 않을 수는 없겠지만 인터페이스까지 의존하는 건 좀 부담된다.

2) 초기화, 종료 메서드 명을 변경할 수 없다.

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

 

따라서 이 방법들은 지금은 거의 사용되지 않는다고 한다.

 

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

설정 정보에 @Bean(initMethod = "init", destroyMethod = "close")와 같이 초기화, 종료 메서드를 지정해줄 수 있다.

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    public void setUrl(final 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();
    }
}

class BeanLifeCycleTest {
    @Test
    void lifeCycleTest() {
        ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        final NetworkClient client = ac.getBean(NetworkClient.class);
        ac.close();
    }

    @Configuration
    static class LifeCycleConfig {
        @Bean(initMethod = "init", destroyMethod = "close")
        public NetworkClient networkClient() {
            final NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hello.dev");
            return networkClient;
        }
    }
}

 

설정 정보 방식의 특징

1) 메서드 이름을 자유롭게 할 수 있다.

2) 스프링 빈 클래스가 스프링 코드에 의존하지 않는다.

3) 코드가 아닌 설정 정보를 이용하기 때문에, 코드를 고칠 수 없는 외부 라이브러리에도 적용이 가능하다.

 

종료 메서드 추론

@Bean의 destroyMethod 속성에는 특별한 기능이 있는데, 바로 종료 메서드 추론 기능이다. 라이브러리는 대부분 close()나 shutdown()을 종료 메서드로서 가진다. 따라서 특별히 종료 메서드를 지정해주지 않으면, 알아서 close나 shutdown이라는 메서드를 자동으로 호출해준다. 참고로 destroyMethod의 디폴트 값은 (inferred)로 등록되어 있다.

 

4. @PostConstruct, @PreDestroy 애노테이션 지원

초기화 메서드와 종료 메서드 앞에 각각 @PostConstruct, @PreDestroy를 붙여주면 되는 아주 간단한 방법이다.

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    public void setUrl(final 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();
    }
}

 

애노테이션 방식의 특징

1) 최신 스프링에서 가장 권장하는 방법이다.

2) 애노테이션 하나만 붙이면 되므로 매우 편리하다.

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

4) 컴포넌트 스캔과 잘 어울린다.

5) 유일한 단점은 외부 라이브러리에는 적용할 수 없다는 것이다. 따라서 외부 라이브러리의 경우, @Bean의 기능을 사용하자.

 

5. 정리

• @PostConstruct, @PreDestroy 애노테이션을 사용하자
• 코드를 고칠 수 없는 외부 라이브러리에 대한 경우에는 @Bean의 initMethod, destroyMethod를 사용하자.