빈 스코프

스코프는 빈이 존재할수 있는 범위

 

싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프

프로토타입: 빈의 생성과 의존관계 주입(초기화 메서드포함)까지만 관여하고 클라이언트에 넘겨주고 더이상 관리하지 않음

 

프로토타입 스코프

-싱글톤은 스프링 컨테이너 생성시점에 스프링 빈을 등록하여 항상 같은 인스턴스의 스프링 빈을 반환

프로토타입은 요청마다 항상 새로운 인스턴스를 생성해서 반환 -> 관리 책임이 클라이언트로 넘어감

-> @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 사용가능