빈 스코프란?
빈이 존재할 수 있는 범위
-
싱글톤 : 기본 스코프, 스프링 컨테이너의 시작~종료
-
프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여
-
웹 관련 스코프
- request : 웹 요청이 들어오고 나갈때까지
- session : 웹 세션이 생성되고 종료될때까지
- application : 웹의 서블릿 컨텍스트와 같은 범위로 유지
프로토타입 스코프
싱글톤 스코프의 빈을 조회하면, 항상 같은 인스턴스의 스프링 빈을 반환
반대로 프로토타입 스코프를 조회하면, 항상 새로운 인스턴스를 생성해서 반환
생성예제
@Scope("prototype")
@Component싱글톤 빈 요청
항상 같은 인스턴스의 스프링 빈 반환
프로토타입 빈 요청
1.스프링 컨테이너가 빈 생성, 의존관계 주입
2.반환하고 끝 (@PreDestroy 호출 ❌)
싱글톤과 프로토타입 함께 사용
프로토타입 빈은 사용할 때마다 새로 생성되는것이 아니고, 요청시마다 새로 생성된다.
프로토타입 빈을 주입받는 클라이언트 빈(싱글톤)이 있다고 가정하자
클라이언트 빈이 주입 시점에 프로토타입빈을 받으면, 프로토타입 빈을 주입받고 내부 필드에 보관한다.
프로토타입 빈은 과거에 주입이 끝났으므로, 항상 같은 참조값을 가지게 된다.
결과적으로, 싱글톤 빈과 함께 프로토타입 빈이 계속 유지되게 된다. 문제점
해결책
DL 방식(dependency Lookup)
프로토타입이 필요할때마다 컨테이너에 새로 요청
프로토타입 빈을 주입받는게 아니라, 의존관계를 조회
ObjectProvider (ObjectFactory)
지정한 빈을 컨테이너에서 찾아주는 DL 서비스 제공
javax.inject.Provider을 통해서도 가능 (자바표준)
프로토타입 빈은 거의 사용할 일이 없다
웹 스코프
특징
- 웹 환경에서만 동작
- 스프링이 해당 스코프의 종료시점까지 관리 => 종료 메서드가 호출
종류
request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지, 각각의 요청마다 별도의 빈 인스턴스가 생성됨session: HttpSession과 동일한 생명주기application: 서블릿 컨텍스트 (ServletContext)와 동일한 생명주기websocket: 웹 소켓과 동일한 생명주기
예제
스코프와 프록시
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {....껍데기를 집어넣어 놓고, 기능을 실제 호출하는 시점에 진짜를 찾아서 동작
ObjectProvider처럼 동작함
Provider이던 프록시던, 진짜 객체 조회를 필요한 시점까지 지연처리
클라이언트는 싱글톤 빈을 쓰는 것처럼, 편리하게 request.scope를 사용 가능
무분별하게 사용하면, 유지보수가 크게 어려워진다
