[스프링 핵심 원리 - 기본편] 9. 빈 스코프

빈 스코프 ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

인프런 김영한 강사님의 스프링 핵심 원리 - 기본편을 수강하고 정리한 글입니다.

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

 

📌 빈 스코프란?

  

✅ 빈 스코프

스프링 라이프사이클을 배울 때를 떠올려 보면, 스프링 빈은 스프링 컨테이너의 시작과 함께 생성되어 컨테이너가 종료될 때까지 유지된다고 배웠다.

 

실은, 이것은 스프링 빈이 기본적으로는 싱글톤 스코프로 생성되기 때문이다.

그런데, 싱글톤 이외에도 스프링 빈이 지원하는 스코프가 있다.

 

1. 싱글톤

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

 

2. 프로토타입

스프링 컨테이너가 프로토타입 빈의 생성과 의존관계 주입 까지만 관여하고, 더 이상은 관리하지 않는 매우 짧은 범위의 스코프.

의존관계 주입 이후로는 관여하지 않기 때문에, 종료 메서드가 호출되지 않는다.

 

  

  

✅ 싱글톤 스코프 vs 프로토타입 스코프

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다.

 

반면, 프로토타입 스코프의 빈을 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

 

  

  

✅ 싱글톤 빈 요청

 

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다.

2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다. (스프링 빈은 이전에 이미 만들어 놓았다.)

3. 같은 요청이 오더라도, 같은 객체 인스턴스의 스프링 빈을 반환한다.

 

  

  

✅ 프로토타입 빈 요청

 

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.

2. 스프링 컨테이너는 이 시점에 프로토 타입 스코프의 빈을 새로 생성하고, 필요한 의존관계를 주입한다.

 

 

3. 스프링 컨테이너는 방금 생성하고 주입했던 프로토타입 빈을 클라이언트에게 반환한다.

4. 이후 스프링 컨테이너에 같은 요청이 오면, 매번 새로운 프로토타입 빈을 생성하고 의존관계를 주입하여 반환한다.

 

 

결국 프로토타입 스코프에서 스프링 컨테이너는 빈을 생성하고, 의존관계를 주입하며 초기화 까지만 진행하고, 이 후에는 관리하지 않는다.

그래서 @PreDestory와 같은 종료 메서드가 수행되지 않는다는 것이다.

 

또, 프로토타입 빈은 클라이언트가 요청했을 때, 반환한 후 아무런 책임도 지지 않고 관리도 하지 않는다.

결국 프로토타입 빈은 그것을 조회한 클라이언트가 관리해야 하고, 종료 메서드에 대한 호출 또한 클라이언트가 직접 수행해야 한다는 것이다.

 

  

  

📌 프로토타입 스코프 - 싱글톤 빈과 함께 사용할 때의 문제점

  

✅ 스프링 컨테이너에 프로토타입 빈 직접 요청하기

 

1. 클라이언트 A는 스프링 컨테이너에 프로토타입 빈을 요청한다.

2. 스프링 컨테이너는 프로토타입 빈을 새로 생성하여 반환한다. (해당 빈의 count 필드 값은 0이다.)

3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하여 count 필드에 +1를 수행한다. 

-> 결과적으로 프로토타입 빈(x01)의 count 값은 1이 된다.

 

 

1. 클라이언트 B는 스프링 컨테이너에 프로토타입 빈을 요청한다.

2. 스프링 컨테이너는 프로토타입 빈을 새로 생성하여 반환한다. (x02) (해당 빈의 count 필드 값은 0이다.)

3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면서 count 필드에 +1을 수행한다.

-> 결과적으로 프로토타입 빈(x02)의 count 값은 1이다.

 

  

  

✅ 싱글톤에서 프로토타입 빈 사용

 

1. clientBean(싱글톤)은 의존관계 자동 주입을 사용한다.

-> 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청했다.

 

2. 스프링 컨테이너는 프로토타입 빈을 생성하여 clientBean에게 반환한다.

- 프로토타입 빈의 count 필드 값은 0이다.

 

이제 clientBean은 프로토타입 빈을 내부 필드에 보관하게 된다. (정확하게는 참조 값을 보관하는 것이다.)

 

 

클라이언트 A는 clientBean을 스프링 컨테이너에 요청하여 받게 된다.

- 싱글톤이므로 항상 같은 clientBean을 반환하게 된다.

 

3. 클라이언트 A는 clientBean.logic()을 호출한다.

 

4. clientBean은 프로토타입 빈의 addCount()를 호출하여 프로토타입 빈의 count가 1 증가 하게 된다.

 

 

클라이언트 B는 clientBean을 스프링 컨테이너에 요청하여 받는다.

- 싱글톤이므로 항상 같은 clientBean이 반환된다.

 

clientBean이 내부에 가지고 있던 프로토타입 빈은 이미 과거에 의존성 주입이 끝난 빈이다.

- 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성된 것이지, 사용할 때마다 새로 생성되는 것은 아니다.

 

5. 클라이언트 B는 clientBean.logic()을 호출한다.

 

6. clientBean은 프로토타입 빈의 addCount()를 호출하여 프로토타입 빈의 count를 증가시킨다.

- 원래 count 값이 1이였으므로, 2가 된다.

 

  

스프링은 일반적으로 싱글톤 빈을 사용한다.

-> 싱글톤 빈이 프로토타입 빈을 사용하게 된다.

 

싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지된다.

프로로타입 빈을 주입 시점에만 새로 생성하는 것이 아니라, 사용할 때마다 새로 생성해서 사용하면 좋을 것 같다.

 

  

  

✅ 프로토타입 스코프와 싱글톤 빈을 함께 사용할 때 : 해결 방법

가장 간단한 방법은 역시 싱글톤 빈이 프로토타입 빈을 사용할 때마다 스프링 컨테이너에 새롭게 요청하는 것이다.

ac.getBean()을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.

 

@Autowired
private ApplicationContext ac;

public int logic() {
   PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
   
   prototypeBean.addCount();
   int count = prototypeBean.getCount();
   
   return count;
}

 

이렇게 의존관계를 외부에서 주입(DI)받는 것이 아니라, 직접 필요한 의존관계를 찾는 것을 DL(Dependency Lookup, 의존관계 조회)라고 한다.

 

그러나 이렇게 되면 스프링 컨테이너에 종속적인 코드가 되어버리고, 단위 테스트 또한 어려워진다.

 

프로토타입 빈을 컨테이너에서 대신 찾아주는 DL 정도의 기능만 제공하는 무언가가 있으면 참 좋을 것 같다.

 

  

  

✅ ObjectFactory, ObjectProvider

지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 바로 

ObjectFactory   

이다.

 

여기에 몇몇 편의 기능을 추가하여 새롭게 생긴 것이 ObjectProvider 이다.

 

@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)

 

딱 필요한 정도의 DL 기능만 제공하므로, 단위테스트 역시 편리하다.

 

 

ObjectFactory는 기능이 단순하다.

ObjectProvider는 ObjectFactory를 상속하며, 편의 기능이 많다.

 

둘 다 스프링에 의존하고 ,별도의 라이브러리가 필요 없다는 점이 공통점이다.

 

  

  

✅ JSR-330 Provider

이러한 ObjectProvider 중, 자바 표준이 바로 JSR-330 이다.

 

provider.get()을 통해 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다. 

get()을 호출하면 내부에서 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)

 

  

  

📌 웹 스코프

  

✅ 웹 스코프 특징

웹 스코프는 웹 환경에서만 동작한다.

 

프로토타입 스코프와 다르게, 스프링이 해당 스코프의 종료 시점까지 관리해준다. 

따라서 종료 메서드가 수행된다.

 

  

  

✅ 웹 스코프 종류

request : HTTP 요청 하나가 들어오고 나갈 때 까지 유지

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

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

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

 

 

 

프로토타입과는 완전히 다른 형태로, HTTP request의 요청이 들어오고 나갈 동안의 life cycle 동안, 같은 애가 관리한다.

 

  

  

📌 스코프와 프록시

  

✅ 프록시

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

 

적용 대상이 인터페이스가 아닌 클래스라면 TARGET_CLASS

적용 대상이 인터페이스면 INTERFACES

 

위 코드에서는 MyLogger의 가짜 프록시 클래스를 만들어 두고, HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

 

CGLIB 라이브러리를 통해 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입하게 된다.

-> 의존관계 주입도 가짜 프록시 객체가 주입된다.

 

가짜 프록시 객체에는 HTTP 요청이 오면 그 때 내부에서 진짜 빈을 요청하는 위임 로직이 존재한다.

 

가짜 프록시 객체는 원본 클래스를 상속 받아 만들어졌기에, 이 객체를 사용하는 클라이언트 입장에서는 원본과 구분을 할 수 없고, 동일하게 사용하게 된다. (다형성)