[Spring] Bean Scope

🔹 Bean Scope

스프링에서 빈은 기본적으로  싱글톤 스코프로 생성된다.

특정 타입의 빈을 하나만 만들어 두고 공유해서 사용하기 위함인데, 이러한 이유로 빈에 상태를 저장하는 코드를 작성하는 것은 동시성 문제를 유발하여 위험한 상황을 초래할 수 있다.

하지만 요구사항과 구현 기능 등의 필요에 따라 비싱글톤이 필요한 경우도 많다. 그리고 이를 명시적으로 구분하기 위해 Scope라는 키워드를 제공한다.

 

🔹 Scope 종류

1. 싱글톤

• 스프링 프레임워크에서 기본이 되는 스코프
• 스프링 컨테이너의 시작과 종료까지 한 개의 객체로 유지된다.
• 가장 넓은 범위의 스코프이다.

2. 프로토타입

• 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프
• 요청이 들어오면 항상 새로운 인스턴스를 생성하여 반환하고 이후에 관리하지 않는다.
• 프로토타입을 받은 클라이언트가 객체를 관리해야 한다.

3. 웹

• request : 각각의 요청이 들어오고 나갈 때까지 유지되는 스코프
• session : 세션이 생성되고 종료될 때까지 유지되는 스코프
• application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

 

빈 스코프는 다음과 같이 @Scope 어노테이션을 통해 지정할 수 있다.

// 자동 빈 등록
@Scope("prototype")
@Component
public class PrototypeBean {
   public PrototypeBean() { }
}

// 수동 빈 등록
@Configuration
class PrototypeBeanConfig {
    @Scope("prototype")
    @Bean
    PrototypeBean prototypeBean() {
        return new PrototypeBean();
    }
}

 

[ 싱글톤 스코프(Singleton Scope) ]

스프링 컨테이너는 기본적으로 싱글톤 스코프를 사용한다.

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

 

스프링 스코프를 설정하는 방법은 Scope를 명시적으로 지정하지 않으면 된다.

// 명시적 지정, 또는 지정하지 않으면 싱글톤 스코프로 관리
@Component
@Scope("singleton")
public class SingletonBean { }

@Component
public class SingletonBean { }

 

[ 프로토타입 스코프(Prototype Scope) ]

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

 

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

싱글톤 빈은 컨테이너 생성 시점에 같이 생성되고 초기화되지만,

프로토타입 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고 초기화 메서드도 실행된다.

 

스프링 컨테이너는 프로토타입 빈을 생성하고, 의존 관계 주입, 초기화까지만 처리한다.

클라이언트에게 빈을 반환한 이후에는 생성된 프로토타입 빈을 관리하지 않는다.

 

프로토타입 빈을 관리할 책임을 컨테이너가 아닌 클라이언트가 가지게 되는 것이다.

따라서 @PreDestory와 같은 종료 콜백 메서드가 호출되지 않는다. 그렇기 때문에 클라이언트가 소멸 메서드(@PreDestory) 같은 것을 자체적으로 관리해 주어야 한다.

 

🤔  그렇다면 프로토타입 스코프는 언제 사용될까?

1. 상태를 가진(Statedul) 빈 사용 시

이해하기 쉽게 온라인 쇼핑 애플리케이션을 생각해 보자.

각 사용자에게 장바구니 역할을 하는 빈이 주어진 경우, 해당 빈은 사용자마다 다른 상태의 구매 항목 목록을 유지해야 한다.

여기에서 싱글톤 스코프를 사용한다면 모든 사용자가 같은 장바구니 인스턴스를 공유하게 되어 문제가 발생할 수 있다.

 

이럴 때 프로토타입 스코프를 사용한다면,

각 요청마다 새로운 장바구니 인스턴스가 생성되어 각 사용자의 상태를 독립적으로 유지할 수 있다.

 

2. 멀티 스레드 환경에서 스레드 안전성(Thread Safety) 보장 필요시

이해하기 쉽게 기숙사에서 사용하는 공용 주방을 생각해 보자.

기숙사에는 여러 사람이 살고 있고, 모두 하나의 공용 주방을 이용해야 한다.

주방에는 하나의 조리 도구 세트만 있어, 여러 사람이 요리를 하려면 전 사람의 요리가 끝날 때까지 기다려야 한다.

이때 사람들에게 각자의 요리 도구 세트를 나눠준다면 전 사람의 요리가 끝날 때까지 기다릴 필요 없어 더 효율적이다.

 

애플리케이션에서 각 스레드(기숙사 사용자)가 독립적으로 작업을 수행하면서 빈의 인스턴스(요리 도구 세트)를 사용해야 하는 경우, 싱글톤 빈을 사용하면 여러 스레드가 동일 인스턴스를 공유하게 되어 스레드 안전성 문제가 발생할 수 있다.

 

이럴 때 프로토타입 스코프를 사용한다면,

각 스레드마다 새로운 빈 인스턴스가 할당되어 독립성을 보장하므로 이러한 문제를 해결할 수 있다.

 

3. 리소스 집약적 인스턴스의 사용 제어

이해하기 쉽게 도서관의 참고 서적을 생각해 보자.

도서관에는 매우 유용하지만 제한된 수량만 있는 참고 서적이 있다.

많은 사람들이 이 서적을 사용하고 싶어 하지만, 동시에 여러 사람이 사용할 경우 손상되거나 필요할 때 사용할 수 없는 문제가 발생할 수 있다. 이러한 문제를 방지하기 위해, 도서관은 참고 서적을 필요할 때만 대여하고 사용 후 반환받아 관리한다. 이를 통해 서적의 상태를 유지하고, 공정하게 접근할 수 있도록 관리할 수 있다.

 

스프링에서 프로토타입 스코프를 사용하는 것은 이러한 도서관 대여 방식과 유사하다.

리소스가 많이 소모되는 빈(참고 서적)을 필요한 시점에만 새로 생성하여 제공한다. 사용이 끝난 빈은 더 이상 유지되지 않는다.

이를 통해 리소스 낭비를 줄이고 빈의 생명주기를 효과적으로 관리하여 애플리케이션의 성능을 최적화할 수 있다.

 

🔸 싱글톤 스코프와 프로토타입 스코프 함께 사용 시 문제점

싱글톤 스코프와 프로토타입 스코프를 함께 사용할 때 주의할 점이 있다.

싱글톤 스코프의 빈이 프로토타입의 빈을 주입받으면 싱글톤의 프로토타입 빈은 매번 바뀌지 않고 같은 빈이 사용된다.

 

싱글톤 빈은 ApplicationContext(스프링 컨테이너)가 처음 애플리케이션을 구동할 때 빈을 만들어주고,

빈을 주입해서 애플리케이션이 종료될 때까지 계속 사용되기 때문에 싱글톤 빈 안에 있는 프로토타입 빈도 처음 그대로 사용되기 때문이다.

 

정리하자면, 싱글톤 빈 안에 프로토타입 빈을 사용하게 된다면 일반 객체(빈)을 사용하는 것과 다를 것 없다.

 

이와 같은 문제를 해결하기 위한 방법으로는 세 가지가 있다.

1. 프록시 모드(Proxy Mode) 이용

// 클래스
@Component
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class PrototypeBean { }

// 인터페이스
@Component
@Scope(value = "prototype", proxyMode = ScopedProxyMode.INTERFACES)
public interface PrototypeInterface { }

프로토타입으로 사용할 빈의 @Scope 어노테이션에 proxy Mode 속성을 ScopedProxyMode.TARGET_CLASS로 설정하여 한다.

만약 해당 빈이 클래스가 아닌 인터페이스라면, ScopedProxyMode_INTERFACE를 사용할 수 있다.

 

이 설정을 사용하면 스프링 컨테이너는 프로토타입 빈을 직접 주입하지 않고, 프로토타입 클래스를 상속받은 프록시 객체를 생성하여 대신 주입한다. 이 프록시 객체는 호출될 때마다 프로토타입 빈의 새로운 인스턴스를 생성하여 반환한다.

 

2. ObjectFactory, ObjectProvider 사용

가장 간단한 방법으로, 싱글톤 빈이 프로토타입의 빈을 사용할 때마다 스프링 컨테이너에 새로 요청하는 방식이다.

 

◽ ObjectFactory

ObjectFactory는 지정된 빈을 스프링 컨테이너에서 찾아주는 의존성 조회(Dependency Lookup, DI) 서비스를 제공한다.

getObject() 메서드만을 제공하며, 이를 통해 빈을 요청할 수 있다. 별도의 라이브러리나 설정이 필요 없으며, 스프링에 의존하는 방식이다.

 

◽ ObjectProvider

ObjectProvider는 ObjectFactory에 다양한 편의 기능(Optional, Stream 등)을 추가한 인터페이스이다.

ObjectFactory의 기능을 확장하여 좀 더 유연한 기능을 제공한다. 또한, 별도의 라이브러리가 필요 없으며, 스프링에 의존한다

 

다음 코드는 싱글톤 빈에서 프로토타입 빈을 매번 새로 요청하는 방식이다.

getObect()를 호출하면 스프링 컨테이너에서 해당 프로토타입 빈을 찾아 반환한다.

@Component
public class Singleton {
    @Autowired
    private ObjectProvider<PrototypeBean> prototypeBeanProvider;

    public PrototypeBean getPrototypeBean() {
        // 매번 새로운 PrototypeBean 인스턴스를 반환받음
        return prototypeBeanProvider.getObject();
    }
}

이 방법을 사용하면 단위 테스트나 Mock 객체를 쉽게 만들 수 있다. 실제 객체와 mock 객체를 구분하여 처리할 수 있어 테스트 코드 작성이 용이하다.

 

3. JSR-330 Provider

이 방법은 jakarta.injection.Provider라는 JSR-330 자바 표준을 사용하는 방법이다.

Provider는 빈을 지연 로딩(lazy loading) 하는 데 사용되는 자바 표준 인터페이스로, 스프링과 같은 DI 컨테이너에 의존하지 않고도 다양한 DI 컨테이너에서 사용할 수 있다.

 

이 방법을 사용하기 위해서는 jakarta.inject 라이브러리를 추가해야 한다.

라이브러리 추가 후, 다음과 같이 사용할 수 있다.

@Component
public class Singleton {
    @Autowired
    private Provider<PrototypeBean> prototypeProvider;
    
    public PrototypeBean getPrototype() {
        // 매번 새로운 PrototypeBean 인스턴스를 반환
        return prototypeProvider.get();
    }
}

Provider.get() 메서드를 호출하면, 스프링 컨테이너에서 해당 프로토타입 빈을 지연 로딩 방식으로 찾아 반환한다. 이를 통해 필요할 때마다 새로운 빈을 요청할 수 있다.

 

Provider는 지연 로딩을 통해 프로토타입 빈을 효율적으로 관리할 수 있으며, 스프링 외 다양한  DI 컨테이너에서도 사용할 수 있다. 또한, 기능이 단순하고 의존성이 적기 때문에 단위 테스트를 작성하거나 Mock 객체를 쉽게 사용할 수 있어 테스트 코드 작성이 용이하다.

 

[ 웹 스코프(Web Scope) ]

웹 스코프는 웹 환경에서만 작동한다. 웹 스코프는 프로토타입 스코프와 다르게 스프링이 해당 스코프 종료 시점까지 관리하므로,  종료 시점에 종료 메서드가 호출됩니다.

 

웹 스코프 빈을 싱글톤 빈에 주입하려고 할 경우 오류가 발생한다. 그 이유는 싱글톤 빈은 애플리케이션 실행 시점에 생성되며, 웹 스코프 빈은 HTTP 요청 시점에 생성되기 때문이다. 따라서 싱글톤 빈이 생성될 때는 웹 스코프 빈이 아직 생성되지 않은 상태여서 의존관계를 주입할 수 없다.

 

즉, 애플리케이션이 실행되자마자 싱글톤 빈은 생성되지만, 웹 스코프 빈은 HTTP 요청이 올 때 생성되므로 웹 스코프 빈을 주입받으려는 시점에서 스프링에서 오류가 발생하는 것이다.

 

이와 같은 문제를 해결하기 위한 방법으로는 두 가지가 있다.

1. Provider 사용

Provider를 사용하면 getObject() 또는 get() 메서드를 호출하는 시점까지 웹 스코프 빈의 생성을 지연시킬 수 있다. 이를 통해 싱글톤 빈이 생성될 때 웹 스코프 빈이 아직 생성되지 않더라도 필요한 시점에만 웹 스코프 빈을 요청할 수 있다.

 

2. Proxy 사용

Proxy를 사용하여 @Scope 어노테이션의 proxyMode를 설정하면, 스프링 컨테이너는 CGLIB라는 바이트코드 조작 라이브러리를 사용하여 웹 스코프 빈을 상속받은 가짜 프록시 객체를 생성한다. 이 프록시 객체는 실제 웹 스코프 빈의 역할을 대신한다.

스프링 컨테이너에는 프록시 객체가 등록되고, 의존관계에서도 프록시 객체가 주입된다. 요청 시점에 프록시 객체가 실제 웹 스코프 빈을 호출하여 필요한 시점에만 빈을 생성하게 된다.

 

이와 같이, Provider와 Proxy를 사용하여 웹 스코프 빈을 안전하게 다룰 수 있다. Provider는 빈을 지연 로딩하며, Proxy는 CGLIB 프록시를 통해 웹 스코프 빈을 대신하는 방식이다. 이 방법들은 프로토타입 빈에서 발생하는 문제를 해결하는 방식과 유사하다.

 

 

 

 

 

📃 reference

• https://mangkyu.tistory.com/117
• https://developshrimp.com/entry/Spring-Bean-Scope