섹션 9. 빈 스코프
빈 스코프 ?
- 빈이 존재할 수 있는 범위
스프링이 지원하는 다양한 스코프
- 싱글톤 : 기본 스코프로, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위
- 프로토타입 : 스프링 컨테이너가 빈의 생성, 의존관계 주입까지만 관여하는 짧은 범위의 스코프
- 웹 관련
- request : 웹 요청이 들어오고 나갈 때 까지 유지되는 스코프
- session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
- application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프
프로토타입 스코프
- 프로토타입 스코프를 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환
- 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리
- 이후 클라이언트에 빈을 반환하고 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않음
public class PrototypeTest {
@Test
void prototypeBeanFind(){
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
System.out.println("find prototypeBean1");
PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
System.out.println("find prototypeBean2");
PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
System.out.println("prototypeBean1 = " + prototypeBean1);
System.out.println("prototypeBean2 = " + prototypeBean2);
Assertions.assertThat(prototypeBean1).isNotSameAs(prototypeBean2);
ac.close();
}
@Scope("prototype")
static class PrototypeBean{
@PostConstruct
public void init(){
System.out.println("PrototypeBean.init");
}
@PreDestroy
public void destroy(){
System.out.println("PrototypeBean.destroy");
}
}
}
/* 출력 결과
find prototypeBean1
PrototypeBean.init
find prototypeBean2
PrototypeBean.init
prototypeBean1 = hello.core.scope.PrototypeTest$PrototypeBean@c05fddc
prototypeBean2 = hello.core.scope.PrototypeTest$PrototypeBean@25df00a0
*/- 프로토타입 빈을 2번 조회 → 각각 다른 빈이 생성되고 초기화(init)도 두번 실행됨
- 조회한 2개의 빈이 다른 것임을 확인할 수 있음
- 빈의 생성과 의존관계 주입까지만 관여하므로 종료 메서드가 실행되지 않음
- 프로토타입 빈을 조회한 클라이언트가 관리하므로 종료 메서드에 대한 호출도 클라이언트가 직접 해야함
프로토타입 빈 + 싱글톤 문제점
- 클라이언트 → 싱글톤 → 프로토타입
- 매번 프로토타입 빈을 새로 생성하여 사용하는 의도에 맞지 않게 프로토타입 빈이 싱글톤 빈과 함께 유지됨
해결 방법
-
싱글톤 빈이 프로토타입 빈을 사용할 때 마다 스프링 컨테이너에 요청
- 의존관계를 외부에서 주입받는게 아니라 직접 필요한 의존관계를 찾는 것을 Dependency Lookup (DL) 의존관계 조회(탐색) 이라함
-
ObjectFactory, ObjectProvider
- 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공 (스프링에 의존)
- 기존 ObjectFactory + 편의 기능 = ObjectProvider
@Autowired private ObjectProvider<PrototypeBean> prototypeBeanProvider; public int logic() { PrototypeBean prototypeBean = prototypeBeanProvider.getObject(); // getObject() 를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환(DL) prototypeBean.addCount(); int count = prototypeBean.getCount(); return count; } -
JSR-330 Provider
- 자바 표준을 사용하는 방법으로 라이브러리를 gradle에 추가해야 함
- 스프링이 아닌 다른 컨테이너에서 사용 가능
@Autowired private Provider<PrototypeBean> prototypeBeanProvider; public int logic(){ PrototypeBean prototypeBean = prototypeBeanProvider.get(); // 새로운 프로토타입 빈이 생성됨 prototypeBean.addCount(); int count = prototypeBean.getCount(); return count; }
웹 스코프
- 웹 환경에서만 동작
- 프로토타입과 다르게 스프링이 종료 시점까지 관리 → 종료 메서드 호출
종류
- request : HTTP 요청마다 각각 별도의 빈이 생성, 관리되며 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프 동시에 여러 HTTP 요청이 들어올 때 어떤 요청이 남긴 로그인지 구분하는데 사용하기 좋음
- session : HTTP Session과 동일한 생명주기를 가지는 스코프
- application : 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프
- websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프
스프링 부트는 웹 라이브러리가 없으면 AnnotationConfigApplicationContext 를 기반으로 애플리케이션을 구동
→ 웹 라이브러리가 추가되면 웹과 관련된 추가 설정과 환경들이 필요하므로AnnotationConfigServletWebServerApplicationContext 를 기반으로 애플리케이션을 구동
스코프와 프록시
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}- 적용 대상이 인터페이스가 아닌 클래스면
TARGET_CLASS를 선택 - 적용 대상이 인터페이스면
INTERFACES를 선택 - 이렇게 하면
MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다. - CGLIB 라는 라이브러리로 가짜 프록시 객체를 만들어 주입 → 스프링 컨테이너에
myLogger라는 이름으로 가짜 프록시 객체를 등록 → 의존 관계에도 가짜 프록시 객체 주입 - 가짜 프록시 객체는 요청이 오면 내부에 진짜 빈을 요청하는 위임 로직이 들어있음 → 내부에서 진짜
myLogger를 찾는 방법을 알고 있음 - 클라이언트는 이게 원본인지 아닌지 모르게 동일하게 사용 가능(다형성)
- 마치 싱글톤 빈을 사용하듯 편리하게 request scope 사용 가능
- Provider, 프록시 모두 진짜 객체 조회를 필요한 시점까지 지연처리
→ 싱글톤을 사용하는 것 같지만 다르므로 주의, 이런 특별한 스코프는 필요한 곳에서만 최소화하여 사용하지 않으면 유지보수에 어려움
mmm