Spring / Bean Scope

빈 스코프

: 빈이 컨테이너 내부에서 존재할 수 있는 범위

 

지금까지 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되었다가 컨테이너가 종료될때까지 유지된다고 배웠다.

기본적으로 스프링 빈이 싱글톤으로 생성되기 때문이다.

 

스프링 빈에는 싱글톤과 프로토타입이 있다.

 

싱글톤 : 기본 빈, 스프링 컨테이너의 시작과 함께 생성 -> 컨테이너 종료직전에 소멸됨.

프로토타입 : 빈의 생성과 의존관계 주입까지만 유지되는 빈. 이 이후에는 컨테이너에서 관리되지 않는다.

 

빈 스코프는 @Scope를 통해 다음과 같이 지정할 수 있다.

 

@Scope("prototype") -> 프로토타입 스코프

@Scope("singleton") -> 싱글톤 스코프

 

 

@Component를 이용한 자동등록

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

 

수동 등록 

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

  지금까지는 계속 싱글톤 스코프를 사용해보았으니, 프로토타입 스코프를 사용해보자

 

---

프로토타입 스코프

싱글톤의 경우 항상 같은 인스턴스의 스프링 빈을 리턴한다.

하지만 프로토타입은 항상 새러운 인스턴스를 생성해서 리턴한다. ( 엄밀히 말하면 인스턴스 생성 후 의존관계 주입까지 마친 후 리턴 )

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

2. 이 시점에 항상 새로운 프로토타입 빈을 생성하고 의존관계를 주입한다.

3. 클라이언트에 리턴

4. 리턴 이후에는 컨테이너에서 관리하지 않는다.

 

여기서 핵심은 컨테이너는 프로토타입 빈을 생성 -> DI -> 초기화 까지만 처리.

빈을 리턴후에는 컨테이너에서 관리 X!!

그래서 @PreDestroy같은 종료 메소드가 호출되지 않음.

 

TestCode

package hello.core.scope;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class PrototypeTest {

    @Test
    void prototypeBeanTest()
    {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ProtoTypeBean.class);
        System.out.println("find prototypeBean1");
        ProtoTypeBean protoTypeBean1 = ac.getBean(ProtoTypeBean.class);
        System.out.println("find prototypeBean2");

        ProtoTypeBean protoTypeBean2 = ac.getBean(ProtoTypeBean.class);


        System.out.println("protoTypeBean1 = " + protoTypeBean1);
        System.out.println("protoTypeBean2 = " + protoTypeBean2);

        Assertions.assertThat(protoTypeBean1).isNotSameAs(protoTypeBean2);

        ac.close();
    }

    @Scope("prototype")
    static class ProtoTypeBean
    {
        @PostConstruct
        public void init()
        {
            System.out.println("ProtoTypeBean.init");
        }

        @PreDestroy
        public void destroy()
        {
            System.out.println("ProtoTypeBean.destroy");
        }
    }
}

종료 메소드가 실행되지 않음.

객체정보를 보면 서로 다른 주소를 가지는 것을 확인할 수 있다.

프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 그리고 초기화 까지만 관여하고, 더는 관리하지 않는다. 따라서 프로토타입 빈은 스프링 컨테이너가 종료될 때 @PreDestroy 같은 종료 메서드가 전혀 실행되지 않는다.

 

프로토타입 빈의 특징

1. 컨테이너에 요청될 때 마다 새로 생성된다.

2. 컨테이너는 프로토타입 빈의 생성, DI, 초기화까지만 관여한다.

3. 종료메소드가 호출되지 않음

4. 그래서 프로토타입빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다.

 

---

프로토타입 - 싱글톤 함께 사용 시 문제점

 

다음과 같은 상황이 있다고 가정해보자.

 

1. SpringContainer내부에 SingletonBean, ProtoTypeBean 생성

2. Singleton -> ProtoTypeBean 의존 @Autowired

3. ClientA가 login() 호출한 뒤 ClientB가 logic()을 호출한 뒤의 count 값은 몇일까? 

 

 

TestCode

package hello.core.scope;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class SingletoneWithProtoTypeTest {

    @Test
    void singleWithProto()
    {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class, ProtoTypeBean.class);

        SingletonBean bean = ac.getBean(SingletonBean.class);
        SingletonBean bean2 = ac.getBean(SingletonBean.class);

        int count1 = bean.logic();
        int count2 = bean2.logic();

        System.out.println("count1 = " + count1);
        System.out.println("count2 = " + count2);

    }

    @Scope("singleton")
    static class SingletonBean
    {
        private final ProtoTypeBean protoTypeBean;

        @Autowired
        public SingletonBean(ProtoTypeBean protoTypeBean) {
            this.protoTypeBean = protoTypeBean;
        }

        public int logic()
        {
            protoTypeBean.addCount();
            return protoTypeBean.getCount();
        }

        @PostConstruct
        public void init()
        {
            System.out.println("SingletonBean.init");
        }

        @PreDestroy
        public void destroy()
        {
            System.out.println("SingletonBean.destroy");
        }

    }
    @Scope("prototype")
    static class ProtoTypeBean
    {
        private int count = 0;

        public void addCount()
        {
            count++;
        }

        public int getCount()
        {
            return this.count;
        }

        @PostConstruct
        public void init()
        {
            System.out.println("ProtoTypeBean.init");
        }
        @PreDestroy
        public void destroy()
        {
            System.out.println("ProtoTypeBean.destroy");
        }
    }
}

Testcode 결과

클라이언트B는 SingletoneBean을 컨테이너에 요청해서 받는다. 싱글톤이므로 항상 같은 SingletonBean이 반환된다.

 

여기서 중요한 점은 SingletonBean이 내부에 가지고 있는 ProtoTypeBean

은 이미 Client A에서 주입이 끝난 빈이다. 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지, 사용할 때마다 새로 생성되는 것이 아니다. 따라서 ClientB는 A가 요청한 count값에서 1 증가하여 2가 된다.

 

스프링은 일반적으로 싱글톤 빈을 사용하므로 싱글톤 빈이 프로토타입 빈을 사용하게 됨.

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

 

---

Provider를 이용한 의존관계 조회 (DL)

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

 

코드로 알아보자

@Scope("singleton")
static class ClientBean
{
    @Autowired private ApplicationContext ac;

    public int logic()
    {
        PrototypeBean bean = ac.getBean(PrototypeBean.class);
        bean.addcount();
        return bean.getCount();
    }
}

 

실행해보면 ac.getBean을 통해 프로토타입 빈을 항상 새로 생성하는 것을 확인할 수 있다.

 

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

그런데 이렇게 Application context 전체를 주입받게 되면, 컨테이너에 종속적인 코드가 되고, 단위 테스트가 어려워짐.

 

 

지금 필요한 기능 : 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는 딱 DL정도의 기능만 제공하는 무언가가 필요.

▶︎ ObjectFactory, ObjectProvider

 

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

 

ObjectProvider를 사용한 예시

    @Scope("singleton")
    static class ClientBean
    {
//        @Autowired private ApplicationContext ac;

        @Autowired
        private ObjectProvider<PrototypeBean> prototypeBeanProvider;

        public int logic()
        {
//            PrototypeBean bean = ac.getBean(PrototypeBean.class);
            PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
            prototypeBean.addcount();
            return prototypeBean.getCount();
        }
    }

 

실행해보면 prototypeBeanProvider.getObject()를 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.

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

 

ObejctFactory 또한 마찬가지

    @Scope("singleton")
    static class ClientBean
    {
//        @Autowired private ApplicationContext ac;

//        @Autowired
//        private ObjectProvider<PrototypeBean> prototypeBeanProvider;

        @Autowired
        private ObjectFactory<PrototypeBean> prototypeBeanObjectFactory;

        public int logic()
        {
//            PrototypeBean bean = ac.getBean(PrototypeBean.class);
//            PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
            PrototypeBean prototypeBean = prototypeBeanObjectFactory.getObject();
            prototypeBean.addcount();
            return prototypeBean.getCount();
        }
    }

차이점

ObjectFactory : 기능이 단순, 별도의 라이브러리 필요 없음, 스프링에 의존

ObjectProvider : ObjectFactory 상속, 옵션, 스트림 처리등 편의 기능이 많고, 별도의 라이브러리 필요 없음, 스프링에 의존

 

스프링 컨테이너에 의존하지 않는 자바 표준 DL도 있다 ▶︎ JSR-330 Provider