🎯 목표 : Bean Scope의 이해

📒 Bean Scope

📌 빈의 생명주기

• 스프링 컨테이너에서의 Bean Scope의 기본 값은 singleton이다.
• 싱글톤 인스턴스는 컨테이너의 생성과 동시에 생성되고, 컨테이너의 소멸 전 인스턴스도 소멸된다.
• 스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료
• 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료 된 후 호출
• 소멸전 콜백 : 빈이 소멸 되기 직전에 호출
• 스프링은 3가지 방법으로 빈의 생명주기 콜백을 지원한다.
  • 인터페이스(InitializingBean, DisposableBean)
  • 설정 정보에 초기화 메소드 종료 메소드 지정 (init(), close() - 자동으로 찾아 콜백함)
  • @PostConstruct @PreDestroy 어노테이션
    1. 최신 스프링에서의 권장하는 방법.
    2. 스프링에 종속적인 기술이 아니라 JSR-250 자파 표준 기술이다.
    3. 컴포넌트 스캔과 잘 어울리며, 외부 라이브러리에는 적용하지 못한다. 외부 라이브러리는 @Bean(initMethod, destroyMethod)의 기능을 사용하면 되겠다.

---

📌 빈 스코프

• Singleton : 기본값, 스프링 컨테이너와 동일하게 유지된다.
• Prototype : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더이상 관리하지 않는다. 매우 짧다
• 웹 관련
  • Request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프.
  • Session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프.
  • Application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프.

---

📌 Prototype Scope

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

public class PrototypeTest {

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

        System.out.println("bean1 = " + bean1);
        System.out.println("bean2 = " + bean2);
        Assertions.assertThat(bean1).isNotSameAs(bean2);
        ac.close();
        /* prototype는 컨테이너가 종료 되더라도 컨테이너의 관리 빈이 아니기떄문에
        *  destroy가 호출 되지 않는다
        * 즉 생성과 의존관계 주입 그리고 초기화 까지만 관여한다.*/
    }
    @Scope("prototype")
    static class ProtoTypeBean {
        @PostConstruct
        public void init() {
            System.out.println("SingletonBean.init");
        }

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

// 출력값
find prototypeBean1
PrototypeBean.init
find prototypeBean2
PrototypeBean.init
bean1 = hello.core.scope.PrototypeTest$ProtoTypeBean@55493582
bean2 = hello.core.scope.PrototypeTest$ProtoTypeBean@1a20270e

• 프로토 타입 빈을 조회와 동시에 초기화 되는 것을 확인 할수 있다
• 초기화가 2번 실행 되는 것을 보면, 서로 다른 빈이라는 것도 확인 할수 있다.
• 하지만, 프로토 타입 빈은 스프링 컨테이너가 생성과 의존 관계 주입 그리고 초기화 까지만 관리하고, 더이상 관리하지 않으므로, 스프링 컨테이너가 종료될 때 Destroy 메소드는 실행되지 않는다.

---

📌 Singleton & Prototype 

• 싱글톤 빈과 프로토 빈이 함께 사용될 때는 의도한 대로 동작하지 않을수도 있다.
• 싱글톤 빈이 프로토 빈을 의존 관계 주입을 받게 되었을때, 
• 클라이언트의 요청은 싱글톤 빈이라고 가정한다면, 싱글톤 빈은 스프링 컨테이너 생성과 종료까지 단 하나의 인스턴스만 존재 하기 때문에 프로토 빈을 주입 받은채로 유지 될 것이다.

public class SingletonWithPrototypeTest1 {
	// TEST1
    @Test
    void singletonClientUsePrototype() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class, ClientBean.class);
        ClientBean bean1 = ac.getBean(ClientBean.class);
        int count1 = bean1.logic();
        assertThat(count1).isEqualTo(1);

        ClientBean bean2 = ac.getBean(ClientBean.class);
        int count2 = bean2.logic();
        assertThat(count2).isEqualTo(2);
		// 출력값
       // PrototypeBean.inithello.core.scope.SingletonWithPrototypeTest1$PrototypeBean@1e097d59
    }

    // TEST2
    @Test
    void singletonClientUseProviderPrototype() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class, ClientBean2.class);
        ClientBean2 bean1 = ac.getBean(ClientBean2.class);
        int count1 = bean1.logic();
        assertThat(count1).isEqualTo(1);

        ClientBean2 bean2 = ac.getBean(ClientBean2.class);
        int count2 = bean2.logic();
        assertThat(count2).isEqualTo(1);
        // 출력값
        //PrototypeBean.inithello.core.scope.SingletonWithPrototypeTest1$PrototypeBean@531f4093
        //PrototypeBean.inithello.core.scope.SingletonWithPrototypeTest1$PrototypeBean@373ebf74
    }

    @Scope("singleton")
    static class ClientBean {
        private final PrototypeBean prototypeBean;
        @Autowired
        public ClientBean(PrototypeBean prototypeBean) {
            this.prototypeBean = prototypeBean;
        }

        public int logic() {
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }
    }

    @Scope("singleton")
    static class ClientBean2 {
        private final Provider<PrototypeBean> prototypeBeanProvider;
        @Autowired
        ClientBean2(Provider<PrototypeBean> prototypeBeanProvider) {
            this.prototypeBeanProvider = prototypeBeanProvider;
        }

        public int logic() {
            PrototypeBean prototypeBean = prototypeBeanProvider.get();
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }
    }


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

        public void addCount() {
            count++;
        }

        public int getCount() {
            return count;
        }

        @PostConstruct
        public void init() {
            System.out.println("PrototypeBean.init"+this);
        }

        @PreDestroy
        public void destory() {
            System.out.println("PrototypeBean.destory");
        }
    }

}

• PrototypeBean을 의존 관계로 주입 받는 ClientBean, ClientBean2 가 있다. 
• TEST1을 보면, ClientBean을 2번 호출하고 각각의 빈이 logic()을 호출 하고 있다.
• 이때, 첫번째 logic() 호출때 count1은 1이 될 것이고, count 2는 2가될 것이다.  ClientBean의 빈의 각각의 호출과 로직의 호출에는 서로 영향을 받는것을 기대 한 것은아니다.
• ClientBean 싱글톤 객체이므로, 첫 인스턴스 생성때 주입받은 PrototypeBean의 의존 관계를 계속 유지하게 되는 것이다.
• 서로 다른 요청이며 첫 요청이 두번째 요청에 영향을 끼치는것을 기대 한 것은 아니기 때문에 싱글톤과 프로토 타입의 빈을 함께 쓰게되면 이러한 문제가 발생 할 수 있다.
• 이러한 문제를 해결하기 위해 Javax.inject.Provider를 사용하면 된다.
• TEST2를 보면 getBean()에 의해 서로 다른 프로토 타입 빈이 생성된 것을 확인 할수 있다.
• ClientBean2에서 Provider의 get()은 내부에서 스프링 컨테이너를 통해 해당 빈을 찾아서 반환하게 된다.
• 이때 의존 관계를 외부에서 주입 받는것(DI)이 아니라 직접 필요한 의존 관계를 찾는 것을 Dependency Lookup(DL)이라 한다. 필요한 의존 관계와 지정한 프로토 타입 빈을 컨테이너에서 대신 찾아주는 역할을 하는 것이다. 

---

📌 Request Scope

• HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프다, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리 된다.
• Request Scope의 라이프 사이클을 알아보기 위해 request scope로 HTTP 요청시에 생성되는 예제 MyLogger 클래스가 있다.

// MyLogger.java
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
/* 가짜 프록시 클래스를 만들어 두고 주입해준다*/
public class MyLogger {
    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("["+uuid+"]"+"["+requestURL+"]"+message);
    }

    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("["+uuid+"]"+" request scop bean create "+this);
    }

    @PreDestroy
    public void close() {
        System.out.println("["+uuid+"]"+" request scop bean close "+this);
    }
}

// LogDemoController.java
@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    /* 서버가 실행될때 request scope 빈은 생성될수가 없다
    *  Provider를 활용해서 해결 해야한다
    *  하지만 MyLogger에서 proxyMode를 사용하면 Provider를 사용할 필요도 없어진다*/
    private final MyLogger myLogger;

    @RequestMapping("/log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
//        MyLogger myLogger = myLoggerProvider.getObject();
        /* 주입해주는 가짜 프록시 클래스를 확인해보자 */
        System.out.println("myLogger = " + myLogger.getClass());

        myLogger.setRequestURL(requestURL);
        myLogger.log("Controller Test");
        logDemoService.logic("testId");
        return "OK";
    }
}

//LogDemoService.java
@Service
@RequiredArgsConstructor
public class LogDemoService {
    /* 서버가 실행될때 request scope 빈은 생성될수가 없다
     *  Provider를 활용해서 해결 해야한다
     *  하지만 MyLogger에서 proxyMode를 사용하면 Provider를 사용할 필요도 없어진다*/
//    private final ObjectProvider<MyLogger> myLoggerProvider;
    private final MyLogger myLogger;


    public void logic(String testId) {
//        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("Service Id = " + testId);
    }
}

• MyLogger를 의존 관계로 주입 받는 LogDemoController와 LogDemoService가 있다.
• request 스코프를 설정 해주는데, proxyMode = ScopedProxyMode.TARGET_CLASS 옵션까지 설정 해 두었다.
• Proxy를 알아보기 전에, request 스코프는 HTTP 요청이 있을때 생성되는 빈이라고 했다.
• 하지만, LogDemoController와 LogDemoService는 MyLogger를 의존하는 Bean 이면서, 싱글톤 Bean이다.
• 싱글톤 빈은 스프링 컨테이너의 생성과 동시에 생성되는 인스턴스인데, HTTP 요청이 있을때 생성되는 MyLogger의 request 스코프 빈의 의존성 주입을 받을수 있을까?
• 만약 Proxy 설정을 하지 않았다면 아래와 같은 에러를 마주치게 된다.

Error creating bean with name 'myLogger': Scope 'request' is not active for the
current thread; consider defining a scoped proxy for this bean if you intend to
refer to it from a singleton;

• request scope 빈이 싱글톤 인스턴스로 부터 의존 하고 있다는 에러다. 생각해보면 당연한 애러다.
• 이러한 문제를 해결하기 위해 Prototype 스코프에서 활용했던 Provider를 활용 해 볼수 있을것이다.
• 더 나아가 Proxy 방식을 사용하게 되면 문제를 더 쉽게 해결 할수 있게 된다.
• proxyMode를 설정해 주고자 한다면, 적용대상이 클래스 일때 TARGET_CLASS를 선택하고, 적용 대상이 인터페이스면 INTERFACES를 선택하면 된다.

System.out.println("myLogger = " + myLogger.getClass());

// 출력값
// myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d

• 위와 같이 myLogger 빈의 클래스 객체를 얻어 출력해 보면, CGLIB라는 것을 볼수 있다.
• CGLIB 라이브러리는 해당 클래스를 상속받은 가짜 객체를 만들어서 먼저 의존성 주입을 하고, 요청이 오면 그때 내부에서 진짜 빈 인스턴스를 요청하여 주입 해준다.
• 즉, 가짜 객체는 실제 request scope와 관계는 없고 내부에 요청이 왔을때 진짜 빈으로 바꿔주는 로직이 있다는 말이다.