빈 스코프

빈 스코프란?

• 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어 스프링 컨테이너가 종료될 때까지 유지되는 이유는 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문
• 스프링이 지원하는 스코프
  • 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 넓은 범위의 스코프
  • 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프
  • 웹 관련 스코프
    • request : 웹 요청이 들어오고 나갈 때까지 유지되는 스코프
    • session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
    • application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

컴포넌트 스캔 자동 등록

@Scope("prototype")
@Component
public class HelloBean {}

수동 등록

@Scope("prototype")
@Bean
PrototypeBean HelloBean(){
    return new HelloBean();
}

싱글톤 스코프

코드

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

싱글톤 빈 요청

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청
2. 스프링 컨테이너는 본인이 관리하는 스프링 빈 반환
3. 이후에 스프링 컨테이너에 같은 요청이 오면 같은 객체 인스턴스의 스프링 빈 반환

프로토타입 스코프

코드

• 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환

프로토타입 빈 요청

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청
2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계 주입
3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환
4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환

프로토타입 빈 특징

• 스프링 컨테이너에 요청할 때마다 새로 생성
• 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입, 초기화까지만 관여
• 종료 메서드가 호출되지 않음
• 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 함

싱글톤 빈에서 프로토타입 빈 사용 시 문제점

코드

• 스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 됨
• 싱글톤 빈은 생성 시점에만 의존관계를 주입받기 때문에 프로토타입 빈이 새로 생성되기는 하지만 싱글톤 빈과 함께 계속 유지됨
• 프로토타입 빈을 사용할 때마다 새로 생성하는 방식으로 사용할 수 없음

싱글톤 빈과 함께 사용시 Provider로 문제 해결

• 위의 문제를 해결하는 가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청하는 것
• 의존관계를 외부에서 주입받는 게 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup(DL, 의존관계 조회)라고 함
• 이렇게 스프링 애플리케이션 컨테스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워짐

ObjectFactory, ObjectProvider

코드

• ObjectProvider가 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공해 줌
• 과거에는 ObjectFactory를 사용했는데, 여기에 옵션, 스트림 처리 등 편의 기능을 추가해서 ObjectProvider가 만들어짐
• ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아 반환함
• 기능이 단순하여 단위테스트를 만들거나 mock 코드를 만들기 쉬워짐
• 별도의 라이브러리 필요 없음
• 스프링에 의존함

JSR-330 Provider

코드

• jakarta.inject.Provider라는 JSR-330 자바 표준을 사용하는 방법
• jakarta.inject:jakarta.inject-api:2.0.1 라이브러리를 gradle에 추가해야 함
• Provider.get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환함
• 자바 표준이고, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기 훨씬 쉬움
• Provider는 딱 필요한 DL정도의 기능만 제공함
• 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용 가능

웹 스코프

• 웹스코프는 웹 환경에서만 동작
• 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리
• 종료 메서드가 호출됨

웹 스코프 종류

• request : HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리됨
• session : Http Session과 동일한 생명주기를 가지는 스코프
• application : 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프
• websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프

웹 환경 추가

• 웹 스코프는 웹 환경에서만 동작하므로 build.gradle에 implementation 'org.springframework.boot:spring-boot-starter-web를 추가해 준다.
• spring-boot-starter-web 라이브러리를 추가하면 스프링 부트는 내장 톰캣 서버를 활용해서 웹 서버와 스프링을 함께 실행시킴
• 웹 라이브러리가 추가되면 AnnotationConfigServletWebServerApplicationContext를 기반으로 애플리케이션을 구동

request 스코프 예제

코드

• 오류 발생함
• 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 실제 고객의 요청이 와야 생성할 수 있음

스코프와 Provider

코드

• ObjectProvider로 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있음
• ObjectProvider.getObject()를 LogDemoController, LogDemoService에서 각각 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환됨

스코프와 프록시

코드

• @Scope에 proxyMode = ScopedProxyMode.TARGET_CLASS 추가
  • 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS
  • 적용 대상이 인터페이스면 INTERFACES
• 가짜 프록시 클래스를 만들어두고 HTTP request와 상관없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있음
• CGLIB라는 라이브러리로 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입
• 가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있음
• 진짜 객체 조회를 필요한 시점까지 지연처리

주의점

• 마치 싱글톤을 사용하는 것 같지만 다르게 동작하므로 주의해서 사용해야 함
• 무분별하게 사용하면 유지보수가 어려우므로 특별한 scope는 필요한 곳에만 최소화해서 사용해야 함

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