빈 스코프

[인프런] 스프링 핵심 원리 - 기본편

 

< 스프링이 지원하는 스코프들 >

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

    • 프로토타입 : 프로토타입 빈의 생성과 의존관계 주입까지만 관여하는 매우 짧은 범위의 스코프

    • 웹 관련 스코프

        ∘ request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프

        ∘ session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프

        ∘ application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

 

// 컴포넌트 스캔 자동 등록
@Scope("prototype")
@Component
public class HelloBean {}

// 컴포넌트 스캔 수동 등록
@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
    return new HelloBean();
}

 

 

📍 프로토타입 스코프

앞서 배웠듯이 싱글톤 빈을 조회하면 항상 같은 스프링 빈을 반환받음

이에 반해, 프로토타입 스코프를 조회하면 항상 새로운 인스턴스를 생성해서 반환해줌

1. 프로토타입 스코프 빈을 스프링 컨테이너에 요청
2. 프로토타입 빈 생성 후, 필요한 의존관계 주입
3. 스프링 컨테이너가 생성한 프로토타입 빈을 클라이언트에게 반환
4. 이후에 다시 요청이 오면 또 새로운 프로토타입 빈을 생성해서 반환

📎 프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 + 초기화 까지만 관여하고 더는 관리하지 않음.

📎 따라서 프로토타입 빈의 관리 책임은 프로토타입 빈을 받은 클라이언트에게 있음 (=> @PreDestroy 호출 X)

 

 

📍 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

싱글톤 빈의 의존 관계 주입 시점에 스프링 컨테이너에 프로토타입 빈 요청

프로토타입 빈 생성 후, 싱글톤 빈에 반환

=> 다시 프로토타입 빈을 요청해도 새로 생성되지 않고, 싱글톤이 앞서 가지고있던 프로토타입 빈을 계속해서 사용

(싱글톤이 해당 프로토타입 빈의 참조값을 계속해서 보관하고 있기 때문)

 

 

📍 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

 

@Scope("singleton")
static class ClientBean {

    @Autowired
    private ObjectProvider<PrototypeBean> prototypeBeanProvider;

    public int logic() {
        PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

prototypeBeanProvider.getObject() : 항상 새로운 빈 생성

ObjectProvider의 getObject() 를 호출하면 스프링 컨테이너를 통해 해당 빈을 찾아서 반환함

=> DL(Dependency Lookup) 의존관계 조회: 의존관계를 외부에서 주입받는게 아니라 직접 필요한 의존관계를 찾는 것

필요할 때 마다 스프링 컨테이너에 요청해서 받는 것이 가능!

 

JSR-330 Provider

: javax.inject.Provider 라는 자바 표준을 사용하는 방법도 있음

javax.inject:javax.inject:1 를 gradle에 추가하면 사용 가능

=> provider.get() 을 통해 사용

 

 

📍 웹 스코프

• 웹 환경에서만 동작함
• 해당 스코프의 종료시점까지 관리해줌 => 종료 메서드도 호출됨

<웹 스코프 종류>

📎 request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프.

                    각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 ,관리됨

📎 session: HTTP Session과 동일한 생명주기를 가지는 스코프

📎 application: ServletContext와 동일한 생명주기를 가지는 스코프

📎 websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

 

 

📍 스코프와 프록시

프록시 방식

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

가짜 프록시 클래스를 만들어주고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 진에 미리 주입해둠

< 과정 >

@Scope(value = "request", proxyMode = ScopeProxyMode.TARGET_CLASS)

• 스프링 컨테이너가 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서 MyLogger를 상속받은 가짜 프록시 객체를 생성함

• 스프링 컨테이너에 myLogger라는 이름으로 가짜 프록시 객체를 대신 등록함

• 의존 관계 주입에도 가짜 프록시가 등록됨

✓ 가짜 프록시 객체는 실제 request scope와 관계가 없음. 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작함