스코프는 빈이 존재할수 있는 범위
싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
프로토타입: 빈의 생성과 의존관계 주입(초기화 메서드포함)까지만 관여하고 클라이언트에 넘겨주고 더이상 관리하지 않음
프로토타입 스코프
-싱글톤은 스프링 컨테이너 생성시점에 스프링 빈을 등록하여 항상 같은 인스턴스의 스프링 빈을 반환
프로토타입은 요청마다 항상 새로운 인스턴스를 생성해서 반환 -> 관리 책임이 클라이언트로 넘어감
-> @PreDestory 같은 종료 메서드는 호출되지 않음
-싱글톤 빈과 함께 사용시에 의도대로 동작하지 않음
-싱글톤 빈에서 프로토타입 빈 사용하면 싱글톤 생성시점에 프로토타입이 주입되어 더이상 생성되지 않음
해결법
ObjectProvider<PrototypeBean> 필요할때마다 스프링 컨테이너에 요청
딱 필요한 DL(Dependency Lookup) 기능 정도 제공, Provider는 자바표준, 테스트만들때 유용
웹스코프(웹 환경)
-스프링이 해당 스코프의 종료시점까지 관리
-웹 관련 스코프
-request: 웹 요청이 하나가 들어오고 나갈때 까지, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리
-session: HTTP 세션이 생성되고 종료될 때까지
-application: 서블릿 컨텍스트(servletContext)와 동일한 생명주기를 가지는 스코프
-websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프
-여러 HTTP 요청이 오면? 로그를 구분하기 힘듦 -> request 스코프
-컨테이너한테 빈 요청하는 단계를 의존관계 주입단계가 아니라 실제 고객요청이 왔을때 요청하도록 지연해야함
-해결법
-Provider로 지연
-ObjectProvider 덕분에 스프링 컨테이너 한테 ObjectProvider.getObject()를 호출하는 시점까지 빈의 생성 요청 지연
-프록시로 지연
-@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
-이렇게 가짜 프록시 클래시를 만들어두고 HTTP requeest와 상관없이 더미 클래스를 다른빈에 미리 주입해두는 방식
-실제 request가 오면 진짜로 바꿔서 동작(바지 사장), 클라이언트 입장에서는 진짜인지 가짜인지 모름
-프록시 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 requestscope 사용가능
'웹 프로그래밍 > 스프링' 카테고리의 다른 글
스프링 MVC(1) 원리 정리 (0) | 2023.04.08 |
---|---|
웹 애플리케이션 이해 (0) | 2023.04.05 |
빈 생명주기(라이프사이클) 콜백 (0) | 2023.02.19 |
스프링 빈 가져올때 팁 (0) | 2023.02.18 |
의존관계 자동 주입 (0) | 2023.02.17 |