[Spring] 빈 생명주기 콜백, 빈 스코프

빈 생명주기 콜백

---

  애플리케이션의 실행 이전에 데이터베이스 커넥션 풀이나 네트워크 소켓과 같이 시작 지점에 필요한 연결을 미리 해두고 애플리케이션 종료 시점에 안전하게 종료하기 위해서는 객체의 초기화 및 종료 작업이 필요하다. 이는 Spring 에서 어떻게 구현할 수 있을까? 

  스프링 빈은 객체를 생성하고 의존관계를 모두 다 주입한 다음에서야 데이터를 사용할 수 있다. 그래서 초기화 작업은 의존관계 주입이 모두 끝난 다음에 호출해야 할텐데, 이 시점을 어떻게 하면 정확하게 알 수 있을까? 이를 위해 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해 초기화 시점을 알려주는 기능을 제공한다. 그리고 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 주기 때문에 이를 이용하여 안전하게 종료 작업을 진행할 수 있다.

 

  [ 스프링 빈의 이벤트 라이프 사이클 ]

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

* 초기화 콜백 : 빈이 생성되고 빈의 의존관계 주입이 완료된 후에 호출

* 소멸전 콜백 : 빈이 소멸되기 직전에 호출

 

 [스프링의 생명주기 콜백]

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

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

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

 

(참고)

  객체의 생성과 초기화는 분리하는 것이 일반적으로 좋다. 생성자는 파라미터를 받고 메모리를 할당해서 객체를 생성하는 책임을 가지고, 초기화는 생성된 값을 활용하여 외부 커넥션을 연결하는 등의 무거운 동작을 수행한다. 그러므로 이러한 역할을 분라히는 것이 유지보수 관점에서 일반적으로 좋다.

  

  싱글톤 빈은 스프링 컨테이너가 종료될 때 같이 종료되기 때문에 스프링 컨테이너가 종료되기 직전에 소멸 전 콜백이 일어난다. 싱글톤과 같이 컨테이너의 시작과 종료까지 생존하는 빈도 있지만 라이프 사이클이 짧은 빈도 있다. 이러한 빈들은 컨테이너와 무관하게 소멸전 콜백이 발생한다.

 

# 인터페이스 (InitializingBean, DisposableBean)

  아래 코드와 같이 InitializingBean, DisposableBean 인터페이스를 구현함에 따라서 빈 생명주기 콜백을 받을 수 있다.

package hello.core.lifercycle;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class NetworkClient implements InitializingBean, DisposableBean {
    private String url; // 접속해야할 서버 URL

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

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

    @Override
    public void afterPropertiesSet() throws Exception {
        // 의존관계 주입이 끝나면 호출한다.
        System.out.println("NetworkClient.afterPropertiesSet");
        connect();
        call("초기화 연결 메세지");
    }

    @Override
    public void destroy() throws Exception {
        // 스프링 컨테이너가 종료되기 직전에 호출한다.
        System.out.println("NetworkClient.destroy");
        disconnect();
    }
}

 

😢 초기화, 소멸 인터페이스의 단점

- InitializingBean, DisposableBean 인터페이스는 스프링 전용 인터페이스이다. 이를 사용하면 스프링 전용 인터페이스에 코드가 의존하게 된다.

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

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

▶ 해당 방법은 스프링 초창기에 주로 사용하던 방법이고, 현재는 다른 방법이 훨씬 좋다.

 

# 빈 등록 초기화, 소멸 메서드 지정

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

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

  위와 같이 함에 따라 메서드 이름을 자유롭게 설정할 수 있으므로 스프링 빈이 스프링 코드에 의존하지 않게 된다. 또한 코드가 아닌 설정 정보를 사용하므로 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다.

 

  @Bean 의 destroyMethod 의 default 는 (inferred) 이다. 대부분의 라이브러리에서 종료 메서드는 close, shutdown 이라는 종료 메서드를 사용하는데 destroyMethod 가 (infferred) 이라면 close, shutdown 라는 이름을 가진 메소드를 자동으로 호출해준다. destroyMethod="" 라고 해주면 추론하지 않는다.

 

# 애노테이션 @PostConstruct, @PreDestroy

@PostConstruct
public void init() throws Exception {
    // 의존관계 주입이 끝나면 호출한다.
    System.out.println("NetworkClient.init");
    connect();
    call("초기화 연결 메세지");
}

@PreDestroy
public void close() throws Exception {
    // 스프링 컨테이너가 종료되기 직전에 호출한다.
    System.out.println("NetworkClient.close");
    disconnect();
}

- 위와 같이 스프링에서는 @PostConstruct, @PreDestroy 애노테이션을 사용하는 방법을 권장한다.

- 스프링에 종속적인 기술이 아니라 JSR-250 이라는 자바 표준으로 스프링이 아닌 다른 컨테이너에서도 동작한다.(javax)

- 하지만 외부 라이브러리에는 적용할 수 없다. 외부 라이브러리를 초기화, 종료해야 하는 경우 @Bean(initMethod="init", destroyMethod="close") 을 활용하자.

 

  # 빈 스코프

  기본적으로 스프링 빈은 싱글톤 스코프로 생성되기 때문에 스프링 컨테이너이 시작되면서 생성되고, 스프링 컨테이너가 종료될 때까지 유지된다.  스프링에서는 다양한 빈 스코프를 지원하며 아래와 같다.

 

1. 싱글톤 : 기본 스코프로, 스프링의 컨테이너의 시작~종료까지 유지되는 가장 넓은 범위의 스코프

2. 프로토타입 : 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프

3. 웹 관련 스코프

    - request: 웹 요청이 들어오고 나갈때 까지 유지됨.

    - session: 웹 세션이 생성되고 종료될 때 까지 유지됨.

    - application: 웹의 서블릿 컨텍스트와 같은 범위로 유지됨.

 

# 프로토타입 스코프

  싱글톤 스코프와 비교해보자. 싱글톤 스코프는 빈을 조회할 시에 스프링 컨테이너가 항상 같은 인스턴스의 스프링 빈을 반환한다. 하지만 프로토 타입 스코프를 스프링 컨테이너에 조회하면, 항상 새로운 인스턴스를 생성해서 변환한다. 스프링 컨테이너가 프로토타입 빈을 생성할 때, 필요한 의존관계 또한 주입해주어서 클라이언트에게 반환한다. 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계를 주입하고 초기화하는 것 까지만 처리하며 이후 관리는클라이언트가 직접 해주어야 한다. 그래서 프로토타입 스코프 핀은 @PreDestroy 와 같은 종료 메서드가 호출되지 않는다.

 

  프로토타입 빈의 특징을 정리하면 아래와 같다.

- 스프링 컨테이너에 요청할 때 마다 새로 생성된다.

- 스프링 컨테이너는 프로토타입 빈 생성과 의존관계 주입, 초기화까지만 관여한다.

- 종료 메서드가 호출되지 않는다.

- 그렇기 때문에 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 직접 관리해야 한다. 종료 메서드에 대한 호출도 필요하다면 클라이언트가 직접 해줘야 한다는 것이다.

 

# 프로토타입 스코프와 싱글톤 빈을 함께 사용할 시 발생하는 문제점

-  스프링 컨테이너에 프로토타입 스코프 빈을 요청하면 요청 시 마다 새로운 객체 인스턴스를 생성해서 반환한다. 다만 싱글톤 빈과 프로토타입 빈을 같이 사용한 경우 의도한 대로 동작하지 않을 수 있으므로 주의해야한다.

-  스프링은 일반적으로 싱글톤 빈을 사용한다. 그래서 싱글톤 빈이 프로토타입 빈을 사용하는데, 싱글톤 빈은 생성 시점에만 의존관계를 주입받기 때문에 프로토 타입 빈이 새로 생성되면 싱글톤 빈과 함께 유지되는 것이 문제를 유발한다. 프로토타입 빈을 사용하는 목적은 사용할 때 마다 새로 생성되어서 사용하는 것일 텐데, 이렇게 하면 주입 시점에만 새로 생성하게 되는데 이는 의도에 반한다. 

-  이와 같이 싱글톤 빈과 프로토타입 빈을 함께 사용 시, 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청하는 것이 가장 간단하다. 이와 같이 필요한 의존관계를 직접 찾는 것을 Dependency Lookup(DL) 이라고 한다. 이 방법으로 해결하는 경우, 스프링 컨테이너에 종속적인 코드가 만들어질 수 밖에 없고 단위 테스트가 어렵다. 딱 DL 기능만 있으면 좋겠는데...?

- 그게 바로 ObjectProvider 이다. (과거에는 ObjectFactory 였는데, 여기에 여러 기능들이 추가되어 ObjectProvider 가 만들어졌다.)

@Scope("singleton")
static class ClientBean {

    @Autowired
    private ObjectProvider<PrototypeBean> prototypeBeanProvider;

    public int logic() {
        PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

- prototypeBeanProvider.getObject() 을 통해서 항상 새로운 프로토타입 빈이 생성된다.

- ObjectProvider 의 getObject() 을 호출하면 내부에서 스프링 컨테이너를 통해 빈을 찾아서 반환한다.(DL)

- ObjectFactory : 기능이 단순, 별도 라이브러리 필요 없고 스프링에 의존

- ObjectProvider : ObjectFactory 상속, 옵션, 스트림 처리와 같은 여러 기능이 있고 별도의 라이브러리가 필요없으며 역시 스프링에 의존.

 

JSR-330 Provider

- javax.inject.Provider 이라는 자바 표준을 사용하는 방법이 있다.  (spring 3.0 은 jakarta.inject.Provider)

- 이를 사용하려면 javax.inject:javax.inject:1 라이브러리를 gradle 에 추가해야 함!

@Scope("singleton")
static class ClientBean {

    @Autowired
    private Provider<PrototypeBean> prototypeBeanProvider;

    public int logic() {
        PrototypeBean prototypeBean = prototypeBeanProvider.get();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

 

- 이는 자바 표준이고 기능이 단순하므로 단위 테스트를 만드거나 mock 코드를 만들기 수월하다.

- 자바 표준이기 떄문에 스프링이 아닌 다른 컨테이너에서도 사용이 가능하다는 것이 특징!

 

[정리]

1. 프로토타입 빈은 사용할 때마다 의존관계 주입이 완료된 새로운 객체가 필요한 경우에 사용한다. 실무에서는 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 드물다고 한다.

2. ObjectProvider, JSR330 Provider 등은 프로토타입 뿐만이 아니라 DL 이 필요한 경우에 이를 이용하여 해결할 수 있으니 기억해두자.

3. 코드를 스프링이 아닌 다른 컨테이너에서도 사용할 가능성이 있다면 JSR-330 Provider 을 사용해야만 한다. 그런 경우가 없을 것 같다면 스프링이 제공해주는 ObjectProvider 을 사용하는 것이 편하다.

 

# 웹 스코프

- 웹 환경에서만 동작함.

- 프로토타입과는 달리 스코프의 종료시점까지 관리함.(종료 메서드가 호출됨)

 

request : HTTP 요청이 들어오고 나갈 때 까지 유지되는 스코프로, 각각의 http 요청마다 별도의 빈 인스턴스가 생성되고 관리됨.

session : HTTP Session 과 동일한 생명 주기를 가짐

application : 서블릿 컨텍스트(ServletContext) 와 동일한 생명주기를 가짐

websocket : 웹 소켓과 동일한 생명주기를 가짐

 

 

 

 

---

Reference

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

스프링 핵심 원리 - 기본편 - 인프런 | 강의