기본 : Section 9
스코프 ? 빈이 존재할 수 있는 범위
- 스프링이 지원하는 스코프
- 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지
- 프로토타입 : 프로토타입 빈의 생성과 의존관계 주입까지만 관여
-
웹 관련 스코프
- request ****: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프 session ****: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프 application ****: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프
컴포넌트 스캔 자동 등록
@Scope("prototype")
@Component
public class HelloBean {}수동 등록
@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
return new HelloBean();
}프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스 생성해서 반환
↔ 싱글톤 스코프 : 항상 같은 인스턴스의 스프링 빈 반환
- 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리 → 프로토타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있음
singleton
public class SingletonTest {
@Test
void singletonBeanFind() {
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class);
SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);
SingletonBean singletonBean2= ac.getBean(SingletonBean.class);
System.out.println("singletonBean1 = " + singletonBean1);
System.out.println("singletonBean2 = " + singletonBean2);
assertThat(singletonBean1).isSameAs(singletonBean2);
ac.close();
}
// SingletonBean.init
// singletonBean1 = hello.core.scope.SingletonTest$SingletonBean@7e094740
// singletonBean2 = hello.core.scope.SingletonTest$SingletonBean@7e094740
// SingletonBean.destroy
@Scope("singleton")
static class SingletonBean {
@PostConstruct
public void init() {
System.out.println("SingletonBean.init");
}
@PreDestroy
public void destroy() {
System.out.println("SingletonBean.destroy");
}
}
}- 초기화 메서드 호출 → 같은 인스턴스 빈 조회 → 종료 메서드 호출
prototype
@Test
void prototypeBeanFind() {
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
System.out.println("find prototypeBean1");
PrototypeTest.PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
System.out.println("find prototypeBean2");
PrototypeTest.PrototypeBean prototypeBean2= ac.getBean(PrototypeBean.class);
System.out.println("prototypeBean1 = " + prototypeBean1);
System.out.println("prototypeBean2 = " + prototypeBean2);
assertThat(prototypeBean1).isNotSameAs(prototypeBean2);
ac.close();
}
// find prototypeBean1
// PrototypeBean.init
// find prototypeBean2
// PrototypeBean.init
// prototypeBean1 = hello.core.scope.PrototypeTest$PrototypeBean@7e094740
// prototypeBean2 = hello.core.scope.PrototypeTest$PrototypeBean@7a11c4c7- 스프링 컨테이너에서 빈을 조회할 때 빈 생성됨 & 초기화 메서드도 실행됨 ↔ 싱글톤 빈 : 생성 시점에 초기화 메서드가 실행
- 초기화 메서드 2번 나타남 (호출될 때마다 객체 생성)
- 종료 메서드 실행 X
- ClientBean : 의존관계 자동 주입 사용, 주입 시점에 스프링 컨테이너에 프로토타입 빈 요청
- 스프링 컨테이너 : 프로토타입 빈 생성해서 ClientBean에 반환, 프로토타입 빈의 count 필드 값 = 0
- 클라이언트 A : ClientBean을 스프링 컨테이너에 요청해서 받음 싱글톤이므로 항상 같은 ClientBean이 반환됨
-
클라이언트 A : ClientBean.logic() 호출
-
clientBean : 프로토타입 빈의 addCount 호출하여 count 증가시킴 프로토타입 빈의 count 필드값 = 1
-
클라이언트 B : ClientBean.logic() 호출
-
clientBean : 프로토타입 빈의 addCount 호출하여 count 증가시킴 프로토타입 빈의 count 필드값 = 2
ClientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈, 주입 받는 시점에 새로운 프로토타입 빈이 생성되는 거지, 사용할 때마다 새로 생성되는 것이 아님!
ObjectProvider : 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공
- 스프링에 의존함, 별도의 라이브러리 필요 업승ㅁ
@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
// getObject : 스프링 컨테이너를 통해 해당 빈을 찾아서 반환
prototypeBean.addCount();
int count = prototypeBean.getCount();
return count;
}
- 스프링 부트 3.0 :
jakarta.inject.Provider
@Autowired
private Provider<PrototypeBean> prototypeBeanProvider;
public int logic() {
PrototypeBean prototypeBean = prototypeBeanProvider.get();
prototypeBean.addCount();
int count = prototypeBean.getCount();
return count;
}-
provider.get(): 항상 새로운 프로토타입 빈 생성provider의get()호출 : 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환 (DL) - 자바 표준이고, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.
-
Provider는 지금 딱 필요한 DL 정도의 기능만 제공한다.
특징
-
get()메서드 하나로 기능이 매우 단순함 - 별도의 라이브러리 필요
- 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용 가능
- 특징
- 웹 환경에서만 동작함
- 스프링이 해당 스코프의 종료시점까지 관리 → 종료 메서드 호출됨
- 종류
- request : HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리된다.
- session : HTTP Session과 동일한 생명주기를 가지는 스코프
-
application : 서블릿 컨텍스트(
ServletContext)와 동일한 생명주기를 가지는 스코프 - websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프
기대하는 공통 포멧: [UUID][requestURL] {message}
UUID를 사용해서 HTTP 요청을 구분하자.
requestURL 정보도 추가로 넣어서 어떤 URL을 요청해서 남은 로그인지 확인하자.
MyLogger
@Component
@Scope(value = "request") // request 스코프로 지정
public class MyLogger {
private String uuid;
private String requestURL;
public void setRequestURL(String requestURL) {
this.requestURL = requestURL;
}
public void log(String message) {
System.out.println("[" + uuid + "]" + "[" + requestURL + "] " + message);
}
@PostConstruct
public void init() { // uuid를 생성해서 저장
uuid = UUID.randomUUID().toString();
System.out.println("[" + uuid + "] request scope bean create:" + this);
}
@PreDestroy
public void close() {
System.out.println("[" + uuid + "] request scope bean close:" + this);
}
}LogDemoController
@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("testId");
return "OK";
}
// HttpServletRequest : 요청 URL 값 (http://localhost:8080/log-demo)
}- 받은 URL 값을 myLogger에 저장
- 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되 지 않는다. 이 빈은 실제 고객의 요청이 와야 생성할 수 있다!
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";
}
-
ObjectProvider덕분에ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있음 -
ObjectProvider.getObject()를 호출하는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리됨
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS) // request 스코프로 지정
public class MyLogger {- 적용 대상이 인터페이스가 아닌 클래스면
TARGET_CLASS를 선택 적용 대상이 인터페이스면INTERFACES를 선택
이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.
<웹 스코프와 프록시 동작 원리>
myLogger 출력결과
myLogger = class hello.core.common.MyLogger$$SpringCGLIB$$0
CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
-
proxyMode = ScopedProxyMode.TARGET_CLASS)를 설정→ 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성함
-
결과를 확인해보면 우리가 등록한 순수한 MyLogger 클래스가 아니라
MyLogger$$EnhancerBySpringCGLIB이라는 클래스로 만들어진 객체가 대신 등록됨 -
스프링 컨테이너에 "myLogger"라는 이름의 가짜 프록시 객체 등록
주의점
- 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
- 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.