스프링 핵심 원리 - 콜백
빈 생명 주기 콜백
데이터베이스 커넥션 풀처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요합니다.
스프링 빈은 객체 생성 후, 의존 관계를 주입하는 순서로 라이프사이클이 동작합니다. 따라서 초기화 작업은 의존 관계 주입이 완료되고 난 다음에 호출해야 합니다. 스프링 빈에게 콜백 메스드를 통해서 이 시점을 알려주는 다양한 기능이 있습니다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 줍니다.
스프링 빈의 이벤트 라이프사이클
- 스프링 컨테이너 생성
- 스프링 빈 생성
- 의존 관계 주입
- 초기화 콜백: 빈이 생성되고 빈의 의존 관계 주입이 완료된 후 호출
- 로직
- 소멸 전 콜백: 빈이 소멸되기 직전에 호출
- 스프링 종료
객체의 생성과 초기화를 분리하는 편이 좋습니다.
생성자는 필수 정보를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가집니다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행합니다. 따라서 이 두 부분을 명확하게 나누는 것이 유지보수 관점에서 좋습니다.
빈 생명 주기 콜백 방법
- 인터페이스 InitializingBean, DisposableBean
- InitializingBean은 afterPropertiesSet() 메서드로 초기화를 지원합니다.
- DisposableBean은 destory() 메서드로 소멸을 지원합니다.
public class NetworkClient implements InitializingBean, DisposableBean {
private String url;
public NetworkClient() {
System.out.println("생성자 호출, 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 {
connect();
call("초기화 연결 메시지");
}
@Override
public void destroy() throws Exception {
disConnect();
}
}이 인터페이스는 스프링 전용 인터페이스로, 해당 코드가 스프링에 의존하게 됩니다. 그리고 초기화, 소멸 메서드의 이름을 변경할 수 없고, 더불어 외부 라이브러리에 적용할 수 없습니다. 이 방법은 최근에는 거의 사용하지 않습니다.
- 빈 등록 초기화, 소멸 메서드 지정
@Configuration
static class LifeCycleConfig {
@Bean(initMethod = "init", destroyMethod = "close")
public NetworkClient networkClient() {
NetworkClient networkClient = new NetworkClient();
networkClient.setUrl("http://hello-spring.dev");
return networkClient;
}
}이 방식은 스프링 코드에 의존하지 않으면서 설정 정보에 메서드를 자유롭게 지정할 수 있습니다. 더불어 외부 라이브러리에도 적용할 수 있습니다.
- 애노테이션 @PostConstruct, @PreDestory
public class NetworkClient {
private String url;
public NetworkClient() {
System.out.println("생성자 호출, 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() {
connect();
call("초기화 연결 메세지");
}
@PreDestroy
public void close() {
disconnect();
}
}최신 스프링에서 가장 권장하는 방법으로, 스프링에 종속적이지 않은 자바 표준입니다. 다만 외부 라이브러리에는 적용하지 못한다는 단점이 있습니다.
빈 스코프
스프링 빈은 기본적으로 싱글톤 스코프로 생성되어 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지됩니다. 하지만 이외에도 다양한 스코프를 지원합니다.
- 싱글톤: 디폴트 스코프로, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프입니다.
- 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존 관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프입니다.
- 웹 관련 스코프
- request: 웹 요청이 들어오고 나갈 때까지 유지되는 스코프입니다.
- session: 웹 세션이 생성되고 종료될 때까지 유지되는 스코프입니다.
- application: 웹의 서블릿 컨텍스와 같은 범위로 유지되는 스코프입니다.
프로토타입 스코프
해당 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환합니다. 여기서 핵심은 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존 관계 주입과 초기화까지만 처리한다는 것입니다. 클라이언트에 빈을 반환한 후 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않습니다. 그래서 @PreDestory 같은 종료 메서드가 호출되지 않습니다.
싱글톤 빈에서 프로토타입 빈 사용시 문제점
싱글톤 빈은 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존 관계 주입도 발생합니다. 따라서 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청해서 내부 필드에 보관합니다. 그런데 싱글톤 빈은 생성 시점에만 의존 관계 주입을 받기 때문에, 프로토타입 빈이 싱글톤 빈과 함께 계속 유지되는 문제가 생깁니다.
Provider로 문제 해결
싱글톤 빈과 프로토타입 빈을 함께 사용할 때마다 항상 새로운 프로토타입 빈을 생성하기 위해서는, 사용할 때마다 스프링 컨테이너에 새로 요청하는 것이 가장 간단한 방법입니다. 이처럼 지정한 비을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 ObjectProvider입니다.
public class SingletonBean {
@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
prototypeBean.addCount();
return prototypeBean.getCount();
}
}- ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환합니다. (DL)
- 이외의 편의 기능을 많이 제공하고, 스프링에 의존적인 점이 특징입니다.
자바 표준의 Provider를 사용하는 방법도 있습니다.
public class SingletonBean {
@Autowired
private Provider<PrototypeBean> prototypeBeanObjectProvider;
public int logic() {
PrototypeBean object = prototypeBeanObjectProvider.get();
object.addCount();
return object.getCount();
}
}- provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환합니다. (DL)
- 별도의 라이브러리가 필요하지만, 자바 표준으로 다른 컨테이너에서도 사용할 수 있는 점이 특징입니다.
웹 스코프
웹 환경에서만 동작하는 스코프로, 스프링이 해당 스코프의 종료 시점까지 관리하여 종료 메서드가 호출됩니다.
웹 소코프 종류
- request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프로, 각각의 HTTP 요청마다 별도의 빈
인스턴스가 생성되고, 관리됩니다. - session: HTTP Session과 동일한 생명주기를 가지는 스코프입니다.
- application: ServletContext와 동일한 생명주기를 가지는 스코프입니다.
- websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프입니다.
requset 스코프 예제
동시에 여러 HTTP 요청이 올 때 정확히 어떤 요청이 남긴 로그인지 구분하기 위해 request 스코프를 사용해보겠습니다.
@Component
@Scope(value = "request")
public class MyLogger {
private String uuid;
private String requestURL;
public void log(String message) {
System.out.println("[" + this.uuid + "]" + "[" + this.requestURL + "] " + message);
}
public void setRequestURL(String requestURL) {
this.requestURL = requestURL;
}
@PostConstruct
public void init() {
this.uuid = UUID.randomUUID().toString();
System.out.println("[" + this.uuid + "] request scope bean create: " + this);
}
@PreDestroy
public void destroy() {
System.out.println("[" + this.uuid + "] request scope bean close: " + this);
}
}- 로그를 출력하기 위한 클래스로, request 스코프로 지정하여 이 빈은 HTTP 요청 당 하나씩 생성되고, HTTP 요청이 끝나는 시점에 소멸됩니다.
- 이 빈이 생성되는 시점에 자동으로 초기화 메서드를 사용해서 uuid를 저장합니다. 이 빈은 HTTP 요청 당 하나씩 생성되므로, 다른 HTTP 요청과 구분할 때 uuid를 사용합니다.
- 이 빈이 소멸되는 시점에 소멸 전 메서드로 종료 메시지를 남깁니다.
@Controller
@RequiredArgsConstructor
public class LogDemoController {
private final LogDemoService logDemoService;
private final ObjectProvider<MyLogger> myLoggerObjectProvider;
// private final MyLogger myLogger;
@RequestMapping("log-demo")
@ResponseBody
public String logDemo(HttpServletRequest request) {
MyLogger myLogger = myLoggerObjectProvider.getObject();
String requestURL = request.getRequestURL().toString();
myLogger.setRequestURL(requestURL);
myLogger.log("controller test");
logDemoService.logic("test id");
return "OK";
}
}@Service
@RequiredArgsConstructor
public class LogDemoService {
private final ObjectProvider<MyLogger> myLoggerObjectProvider;
// private final MyLogger myLogger;
public void logic(String id) {
MyLogger myLogger = myLoggerObjectProvider.getObject();
myLogger.log("service id = " + id);
}
}- 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되지 않기 때문에 MyLogger 빈이 아직 만들어지기 전입니다.
- 이를 해결하기 위해 Provider를 사용해서 request 스코프 빈의 생성을 지연할 수 있습니다.
스코프와 프록시
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}- 프록시 방식으로, MyLogger의 가짜 프록시 클래스를 만들어두고, HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해둘 수 있습니다.
@Controller
@RequiredArgsConstructor
public class LogDemoController {
private final LogDemoService logDemoService;
private final MyLogger myLogger;
@RequestMapping("log-demo")
@ResponseBody
public String logDemo(HttpServletRequest request) {
String requestURL = request.getRequestURL().toString();
myLogger.setRequestURL(requestURL);
myLogger.log("controller test");
logDemoService.logic("test id");
return "OK";
}
}@Service
@RequiredArgsConstructor
public class LogDemoService {
private final MyLogger myLogger;
public void logic(String id) {
myLogger.log("service id = " + id);
}
}- CGLIB라는 라이브러리로 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입합니다.
- 가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어 있습니다.
- 가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있습니다.(다형성)
스프링 핵심 원리 기본편 정리
스프링 핵심 원리 기본편 강좌 정리본입니다.
velog.io