Bean Scope

@Scope("{스코프종류}")
@Component
public class prototypeBean {}
  • 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프

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

  • 웹 관련 스코프

    • request: 웹 요청이 들어오고 나갈때까지 유지

    • session: 웹 세션이 생성되고 종료될 때 까지 유지

    • application: 웹의 서블릿 컨텍스와 같은 범위로 유지

싱글톤

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

  2. 스프링 컨테이너는 본인이 관리하는 스프링 빈 반환

  3. 스프링 컨테이너에 같은 요청이 와도 같은 인스턴스의 스프링 빈 반환

싱글톤 스코프의 빈은 동일한 빈을 생성하는 것을 확인할 수 있다. 또한 스프링 컨테이너 생성 시점에 초기화 메서드가 실행되며, 스프링컨테이너 종료전 @PreDestroy 메서드가 호출되는 것을 확인할 수 있다.

프로토타입

스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다. 프로토타입 빈을 관리할 책음은 프로토타입 빈을 받은 클라이언트에 있다.(@PreDestroy 같은 종료 메서드가 호출되지 않음.)

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

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

  3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환

  4. 같은 요청이 와도 항상 새로운 프로토타입 빈을 생성해서 반환

  • 스프링 컨테이너에서 빈을 조회할때 생성된다. (초기화 2번된 것 확인 가능)

  • prototypeBean1과 prototypeBean2의 주소가 다른것을 확인할 수 있다. 즉, 새로운 빈을 생성한다.

  • 또한, 프로토타입 빈은 스프링 컨테이너가 생성, 의존관계 주입, 초기화 까지 관여하므로 스프링 컨테이너 종료시 @PreDestroy 종료메서드인 destroy() 가 호출되지 않은 것을 확인할 수 있다.

만약 프로토타입 빈을 종료하고 싶은 경우에는 직접 아래와 같이 해당 메서드를 호출해줘야한다.

프로토타입 스코프를 싱글톤 빈과 함께 사용하고 싶다면?

싱글톤 빈과 프로토타입 빈을 함께 사용할 때, 매번 새로운 프로토타입 빈을 생성하고 싶은 경우에는 Provider를 이용하면된다.

ObjectProvider

지정한 빈을 컨테이너에서 대신 찾아주는 DL(Dependency Lookup - 의존관계를 찾음) 서비스를 제공한다.

이때 ObjectProviderObjectFactory 를 상속받고 있다.

ObjectFactory

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

JSR-330 Provider

자바표준 Provider를 사용하려면, 해당 라이브러리를 추가해줘야한다.

  • build.gradle

prototypeBeanProvider.get() 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.(DL) 자바 표준이며, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.

하지만, 별도 라이브러리가 필요하며, 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다.

웹 스코프

  • 웹 환경에서만 동작

  • 스프링 컨테이너가 해당 스코프의 종료시점까지 관리한다. ( 종료메서드 호출됨 )

종류

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

  2. session: HTTP Session과 동일한 생명주기

  3. application: 서블릿 컨텍스트(ServletContext)와 동일 생명주기

  4. websocket: 웹 소켓과 동일한 생명주기

request

웹환경이 동작하도록, 해당 라이브러리를 우선 추가해준다.

request 스코프는 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분할 때 사용하기 좋다.

  • request scope object

@Scope("request") 이므로 HTTP 요청당 하나씩 생성되며, HTTP 요청이 끝나는 시점에 소멸된다.

  • controller

  • service

각각 요청별로 log가 남는것을 볼 수 있다.

프록시

proxyMode = ScopedProxyMode.TARGET_CLASS 추가로 가짜 프록시 클래스를 만들어두고, HTTP request와 상관없이 가짜 프록시 클래스를 다른 빈에 미리 주입해둘 수 있다.

ScopedProxyMode

  • DEFAULT: 컴포넌트 스캔 레벨

  • NO: 프록시를 생성하지 않는다.

  • INTERFACES : 적용대상이 인터페이스인 경우

  • TARGET_CLASS : 적용 대상이 클래스인 경우

http://localhost:8080/log-demo 요청 로그 확인

클래스를 확인해보녀 순수한 MyLogger 클래스가 아니라 MyLogger$$EnhancerBySpringCGLIB​ 이라는 클래스로 만들어진 객체가 대신 등록되었다.

또한, 스프링 컨테이너에 프록시 객체를 등록하며, 의존 관계 주입도 프록시 객체가 주입된다.

동작 원리

  1. CGLIB 라이브러리로 내 클래스를 상속 받은 프록시 객체를 만들어서 주입

  2. 프록시 객체는 실제 요청이 들어오면 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.

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

즉, 프록시 객체를 사용하여 클라이언트는 싱글톤 빈을 사용하듯이 request scope를 사용할 수 있다. 어노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있으며, 이는 다형성과 DI 컨테이너가 가진 가장 큰 강점이다.

하지만, 싱글톤을 사용하는 것처럼 느껴지지만 싱글톤과는 다르게 동작하기 때문에 주의해서 사용해야한다. 특별한 곳에서만 최소화해서 사용해야한다. 만약 무분별하게 사용하게 된다면 유지보수 및 테스트가 어려워진다.

참고

Last updated

Was this helpful?