Bean Scope
: 빈이 존재할 수 있는 범위
다양한 Scope
- Singleton
- 기본 스코프
- 스프링 컨테이너의 시작과 종료까지 유지되는, 가장 넒은 범위의 스코프
- Prototype
- 스프링 컨테이너는 생성과 의존관계 주입가지만 관여
- 그 이후는 관리하지 않음
- 매우 짧은 범위의 스코프
Web 관련 Scope
- request : 웹 요청이 들어오고 나갈 때까지 유지되는 스코프
- session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
- application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프
Singleton Bean Scope
- 스프링 컨테이너가 소멸때까지 관리함
Prototype Bean Scope
- 스프링 컨테이너는 생성과 의존관계 주입, 초기화까지만 관리하고, 다시 유저에게 반환해버림
- 즉, 보관하지 않기 때문에 매번 생성해서 반환함
- 따라서
@PreDestroy와 같은 종료메서드가 호출되지 않는다.
문제 사항
- 스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다.
- 단, 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 생성 단계에서 생성된 후 유지되는 것이 문제!!
보통은, 이런 경우를 피하고 싶어서 프로토타입 빈을 사용한다. 따라서 의도와 다르게 동작할 가능성 ↑
Singleton Bean + Prototype Bean
- Client Bean : 싱글톤이기 때문에, 스프링 컨테이너 생성 시점에 생성된 후 의존관계 주입도 발생
- Prototype Bean을 스프링 컨테이너에 요청
- 그 후 clientBean이 prototypeBean을 내부 필드에 보관
- clientBean은 요청이 들어올 때마다 같은 빈을 반환함
- clientBean.logic()이 호출되면, clientBean은 prototypeBean의 addCount() 호출 → prototype의 count 1 증가
이 경우, prototypeBean의 count는 2로 증가하게 된다 → 프로토타입 빈의 특성과 맞지 않는 결과!
Provider 사용하기
방법 0. 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청
-
Dependency Lookup(DL) : 의존관계 조회(탐색)
- 외부에서 의존관계를 주입받는 것이 아니라, 직접 필요한 의존관계를 찾는 것
-
단, 이렇게 스프링 ApplicationContext 전체를 주입받는 것은 권장되지 않는다!
- 스프링 컨테이너에 종속적인 코드가 됨
- 단위 테스트가 어려워짐
-
지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는, DL 정도의 기능만 제공하는 무언가만 있으면 됨
방법 1. ObjectProvider
원래는 ObjectFactory가 있었는데, 여기에 편의 기능을 추가해서 ObjectProvider가 만들어짐!
- 지정한 Bean을 컨테이너에서 대신 찾아주는 DL 서비스를 함
@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
prototypeBean.addCount();
int count = prototypeBean.getCount();
return count;
}getObject()메서드를 통해, 항상 새로운 프로토타입 빈을 생성함- 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아 반환함
특징
- ObjectFactory
- 기능이 단순함
- 별도의 라이브러리 필요 없음
- 스프링에 의존함
- ObjectProvider
- ObjectFactory 상속
- 옵션, 스트림 처리 등 편의 기능이 많음
- 별도의 라이브러리 필요 없음
- 스프링에 의존
방법 2. JSR-330 Provider
javax.inject.Provider
(jakarta.inject.Provider - Spring Boot 3.0 이상)
- JSR-330 자바 표준을 사용
@Autowired
private Provider<PrototypeBean> provider;
public int logic() {
PrototypeBean prototypeBean = provider.get();
prototypeBean.addCount();
int count = prototypeBean.getCount();
return count;
}특징
get()메서드 하나 - 기능이 매우 단순- 별도의 라이브러리가 필요함
- Java 표준임 → 스프링이 아닌 다른 컨테이너에서도 사용할 수 있음
📌 하나 더!
- 스프링이 제공하는 메서드 중 @Lookup 애노테이션도 있음
- 단, 위의 방법들로도 충분함
- 고려해야 할 내용도 많음
👉🏻 참고 사항
- 다만, 실무에서 웹 애플리케이션을 개발해보면 싱글톤 빈만 사용해도 대부분의 문제를 해결할 수 있음 → 프로토타입 빈을 직접적으로 사용하는 일은 매우 드묾
💡 Tip!
- ObjectProvider, JSR330 Provider 등 : 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용 가능
- ex) 순환 참조 방지용
Java 표준 vs Spring 제공 기능?
위의 방법 2와 3을 보면, 둘 중 어느 것을 사용할지 고민이 될 수 있다.
-
만약 (거의 없지만) 코드를 스프링이 아닌 다른 컨테이너에서도 사용할 수 있어야 한다면, 자바 표준을 써야 한다.
-
스프링은 이제 사실상 기술의 표준에 가까움
-
다만, 대부분의 경우 위와 같은 일이 엇고, 스프링이 대부분 더 다양하고 편리한 기능을 제공해주기 때문에 특별한 일이 없다면 스프링이 제공하는 기능을 사용해도 좋다.
Web Scope
- 웹 환경에서만 동작한다.
- 프로토타입과 다르게 스프링이 해당 스코프의 종료 시점까지 관리한다.
- 따라서 종료 메서드가 호출된다.
종류 1. request
- HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 Scope
- 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리된다.
종류 2. session
- HTTP Session과 동일한 생명주기를 가짐
종류 3. application
- ServletContext와 동일한 생명주기를 가짐
종류 4. websocket
- 웹 소켓과 동일한 생명주기를 가짐
📌 실습 시 참고!
spring-boot-starter-web 라이브러리를 추가하면 스프링 부트는 내장 톰켓 서버를 활용해서 웹
서버와 스프링을 함께 실행시킨다.
📌 실습 시 참고! 2
- 스프링 부트는 웹 라이브러리가 없으면 우리가 지금까지 학습한
AnnotationConfigApplicationContext을 기반으로 애플리케이션을 구동한다.- 웹 라이브러리가 추가되면 웹과 관련된 추가 설정과 환경들이 필요하므로
AnnotationConfigServletWebServerApplicationContext를 기반으로 애플리케이션을 구동하면 된다.
request Scope
- 동시에 여러 HTTP 요청이 오면 → 정확히 어떤 요청이 남긴 로그인지 구분하기 어려워짐
- 이럴 때 request 스코프를 사용하면 좋음!
@Scope(value = "request")- HTTP 요청 당 하나씩 생성됨
- HTTP 요청이 끝나는 시점에 소멸됨
- 다른 HTTP 요청 때문에 섞이는 걱정 안해도 됨
📌 참고!
- requestURL 로그를 남기는 부분 등은 컨트롤러보다는 스프링 인터셉터나 서블릿 필터 등을 활용하는 것이 좋음
Provider
-
Controller
@Controller @RequiredArgsConstructor public class LogDemoController { private final LogDemoService logDemoService; private final ObjectProvider<MyLogger> myLoggerProvider; @RequestMapping("log-demo") @ResponseBody public String logDemo(HttpServletRequest request) { String requestURL = request.getRequestURL().toString(); MyLogger myLogger = myLoggerProvider.getObject(); myLogger.setRequestURL(requestURL); myLogger.log("controller test"); logDemoService.logic("testId"); return "OK"; } } -
Service
@Service @RequiredArgsConstructor public class LogDemoService { private final ObjectProvider<MyLogger> myLoggerProvider; public void logic(String id) { MyLogger myLogger = myLoggerProvider.getObject(); myLogger.log("service id = " + id); } } -
ObjectProvider을 사용하면?-
ObjectProvider.getObject()를 호출하기 전까지 request scope 빈의 생성 지연 가능 -
ObjectProvider.getObject()` 호출 시점에는 HTTP 요청이 진행 중이므로 request scope 빈의 생성이 정상 처리됨
-
ObjectProvider.getObject()를LogDemoController,LogDemoService에서 각각 한번씩 따로 호출해도, 같은 HTTP 요청이면 같은 스프링 빈이 반환됨
-
Proxy
활용 방법
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}- MyLogger의 가짜 프록시 클래스를 만들어두고, HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 주입해둘 수 있다.
- 적용 대상이 클래스 : TARGET_CLASS
- 적용 대상이 인터페이스 : INTERFACES
주입된 myLogger
System.out.println("myLogger = " + myLogger.getClass());myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d- CGLIB라는 바이트코드를 조작하는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
- 스프링 컨테이너는 CGLIB를 사용해서,
MyLogger를 상속받은 가짜 프록시 객체를 생성한다. - 스프링 컨테이너에 "
myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다 - 그래서 의존관계 주입도 이 가짜 프록시 객체가 주입된다!
그럼 어떻게 동작하는가?
- 가짜 프록시 객체
- 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있음
- 내부에 진짜
myLogger를 찾는 방법을 알고 있음 - 클라이언트가
myLogger.logic()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것 → 가짜 프록시 객체가 request scope를 가진 진짜myLogger.logic()를 호출한다. - 원본 클래스를 상속 받아서 만들어짐 → 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있음(다형성)
정리!
가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만
있고, 싱글톤 처럼 동작한다.
장점
- 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
- 사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
- Proxy : 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. (이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.)
- 꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다 (나중에 나오는 AOP 원리가 딱 이것임)
주의점
- 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
- 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자 (무분별하게 사용하면 유지보수하기 어려워진다!)
