빈 생명주기 콜백
데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.
스프링 빈의 라이프사이클
객체 생성 > 의존관계 주입
스프링 빈의 이벤트 라이프사이클
스프링 컨테이너 생성 > 스프링 빈 생성 > 의존관계 > 주입초기화 콜백 > 사용 > 소멸전 콜백 > 스프링 종료
스프링의 생명주기 콜백
1. 인터페이스
- 이 방법은 스프링 초창기에 나온 방법들로 지금은 거의 사용하지 않는다.(InitializingBean, DisposableBean)
- 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
- 초기화, 소멸 메서드의 이름을 변경할 수 없다.
- 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.
2. 빈 등록 초기화, 소멸 메서드 지정
- 메서드 이름을 자유롭게 줄 수 있다.
- 스프링 빈이 스프링 코드에 의존하지 않는다.
- 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다
3. @PostConstruct, @PreDestroy 애노테이션
- @PostConstruct, @PreDestroy이 두 애노테이션을 사용하면 가장 편리하게 초기화와 종료를 실행할 수 있다.
- 최신 스프링에서 가장 권장하는 방법이다.
- 애노테이션 하나만 붙이면 되므로 매우 편리하다.
- 스프링이 아닌 다른 컨테이너에서도 동작한다.
- 컴포넌트 스캔과 잘 어울린다.
- 유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다.
느낀점
왠만하면 빈 라이프사이클을 조정할때에는 @PostConstruct, @PreDestroy 애노테이션을 사용하자.
코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 initMethod사용하자.
빈 스코프
빈 스코프란 빈이 존재할 수 있는 범위를 뜻한다.
1. 싱글톤
: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.
2. 프로토타입
: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.
- 스프링 컨테이너에 요청할 때 마다 새로 생성된다.
- 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.
- @PreDestroy같은 종료 메서드가 호출되지 않는다. 그래서 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다. 종료 메서드에 대한 호출도 클라이언트가 직접 해야한다.
3. 싱글톤 빈에서 프로토타입 빈 사용
- 싱글톤 빈과 프로토타입 빈을 함께 사용시 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되는 것이 문제다.
- 그에 해결방법으로는 Provider이 있다.
- 가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할 때 마다 스프링 컨테이너에 새로 요청하는 것이다.
- 의존관계를 외부에서 주입(DI) 받는게 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup (DL) 의존관계 조회(탐색) 이라한다
- ObjectFactory, ObjectProvider, JSR-330 Provider 등이 있다
4. 웹 관련 스코프
- request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.
- session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.
- application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.
- websocket:웹 소켓과 동일한 생명주기를 가지는 스코프이다.
@Scope(value = "request") 를 사용해서 request 스코프로 지정했다. 이제 이 빈은 HTTP 요청 당 하나씩 생성되고, HTTP 요청이 끝나는 시점에 소멸된다.
하지만 이렇게 생성한 request 스코프 빈은 스프링 애플리케이션을 실행하는 시점에 주입이 되지 않아 오류가 발생한다.
스코프 주입 오류 해결
1. 스코프와 Provider
저렇게 MyLogger Class를 ObjectProvider형식인 myLoggerProvider 생성 해두면 직접 myLoggerProvider.getObject()을 호출하는 시점까지 request scope 인 MyLogger Class의 생성을 지연할 수 있어 우회가 가능하다.
2. 스코프와 프록시
해당 방식은 Scope의 proxyMode = ScopedProxyMode.TARGET_CLASS)를 설정하면 스프링 컨테이너는 CGLIB 라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성한다. 그렇게 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
느낀점
스프링 빈의 생명주기인 스코프에 대해 알 수 있었다.
프로토타입 빈은 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다는것.
Provider, 프록시의 핵심은진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점.(DL기능)
애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다는것.
이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용해야 한다는것.
결론
이렇게 스프링 핵심 원리 - 기본편을 모두 수강했다.
회사를 다니며 퇴근하고 남는시간 1~2시간을 소요하며 진행하려니 생각보다 진행이 더디게 되어 중간부턴 출,퇴근 이동시간을 활용하며 진행했다.
내가 평소에 사용만 해왔던 스프링의 핵심 원리와 기본에 대한 개념을 잡을 수 있던거 같다.
나는 아직 한참 모자라다는걸 깨달았고 앞으로 꾸준히 노력하며 성장하는 개발자가 되고싶다고 느꼈다.
이제 스프링을 직접 활용해보며 추후에 스프링 핵심 원리 - 고급편을 수강할 계획이다.
