빈 스코프(Bean Scope)란?

빈 스코프란?

- 빈의 수명 범위(언제부터 언제까지 살아 존재하는가에 대한 범위)

- 직독직해하면 빈의 범위라는 의미이다.

- 싱글톤이 아닌 방법으로 빈을 구성해야 하는 경우 구분하기 위해 스프링에서 scope라는 키워드를 사용

빈 스코프의 종류

- 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.

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

- 웹 관련 스코프

  - request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.

                  단일 Bean 정의의 범위를 단일 HTTP 요청의 수명 주기로 지정

  - session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.

  - application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.

싱글톤

- 미리 빈을 생성해 놓는다.

- 매번 같은 인스턴스의 빈을 반환한다

package hello.core.scope;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.assertThat;
public class SingletonTest {
    @Test
    public void singletonBeanFind() {
        AnnotationConfigApplicationContext ac = new
                AnnotationConfigApplicationContext(SingletonBean.class);
        SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);
        SingletonBean singletonBean2 = ac.getBean(SingletonBean.class);
        System.out.println("singletonBean1 = " + singletonBean1);
        System.out.println("singletonBean2 = " + singletonBean2);
        assertThat(singletonBean1).isSameAs(singletonBean2);
        ac.close(); //종료
    }
    @Scope("singleton")
    static class SingletonBean {
        // 호출
        @PostConstruct
        public void init() {
            System.out.println("SingletonBean.init");
        }
        // 호출
        @PreDestroy
        public void destroy() {
            System.out.println("SingletonBean.destroy");
        }
    }
}

프로토타입

- 요청이 오면 그 때 매번 새로운 빈을 생성

- 빈 반환한 후에 관리X

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

- 생성된 프로토타입 빈은 클라이언트가 관리해야 한다.

package hello.core.scope;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.*;
public class PrototypeTest {
    @Test
    public void prototypeBeanFind() {
        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);
        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");
        }
    }
}

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

- 싱글톤 빈에서 프로토타입 빈을 한번 주입받으면 주입 시점에만 새로운 빈을 생성 받는다.

- 요청 시마다 새로운 빈을 받지 못함 -> 프로토타입 빈의 사용 의미가 사라짐

- DL(Dependency Lookup): 의존 관계를 외부에서 주입(DI) 받는 게 아니라 직접 필요한 의존 관계를 찾는 것

ObjectFactory, ObjectProvider

- 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스 제공

- ObjectFactory를 상속받은 ObjectProvider(기능 더 추가됨)

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

private final ObjectProvider<PrototypeBean> prototypeBeanProvider;

@Autowired
public ClientBean(ObjectProvider<PrototypeBean> prototypeBeanProvider) {
    this.prototypeBeanProvider = prototypeBeanProvider;
}

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

JSR-33- Provider

- 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다

- 별도의 라이브러리가 필요하다 (javax.inject:javax.inject:1)

- get() 메서드 하나로 기능이 매우 단순하다

@Autowired
private Provider<PrototypeBean> provider;
public int logic() {
     PrototypeBean prototypeBean = provider.get();
     prototypeBean.addCount();
     int count = prototypeBean.getCount();
     return count;
}

* 실무에서는 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물다.

웹 스코프

- request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의(전용) 빈 인스턴스가 생성되고, 관리된다.

- session: HTTP Session과 동일한 생명주기를 가지는 스코프

- application: 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프

- websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

스코프와 Provider

- Logger 출력될 문구 형식

package hello.core.common;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import java.util.UUID;

@Component
// request scope
@Scope(value = "request")
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 scope bean create:" + this);
    }
    // 응답 직전에 호출
    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

- 컨트롤러

package hello.core.web;
import hello.core.common.MyLogger;
import hello.core.logdemo.LogDemoService;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import javax.servlet.http.HttpServletRequest;

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    private final LogDemoService logDemoService;
    private final ObjectProvider<MyLogger> myLoggerProvider;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

- 서비스

package hello.core.logdemo;
import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final ObjectProvider<MyLogger> myLoggerProvider;

    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("service id = " + id);
    }
}

- 결과

  -> http요청을 http://localhost:8080/log-demo로 하면 다음과 같은 결과가 나온다

- request 빈의 생성 시점(스프링에 생성 요청)을 늦추기 위해(요청이 될 때 생성되게 만들기 위해) Provider를 사용

- 요청 별로 전용 빈을 할당하는 특징도 그대로 사용 가능.

프록시 방식

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

- 적용 대상이 클래스면 TARGET_CLASS를 선택

- 적용 대상이 인터페이스면 INTERFACE를 선택

- MyLogger에 가짜 프록시 클래스를 만들어두고 HTTP Request와 상관없이 가짜 프록시(대행사) 클래스를 다른 빈에 미리 주입해 둘 수 있다.

- proxyMode를 설정하고 난 뒤에는 Provider 사용 이전으로 돌려놓아도 그대로 동작한다

private final MyLogger myLogger;

- CGLIB라는 라이브러리로 MyLogger 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입한다

myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d

- 가짜 프록시는 파견 대행사 역할을 한다.

- 호출되는 순간 실제 MyLogger 클래스(실물)의 메소드를 호출한다.

- 의존관계 주입도 가짜 프록시 객체가 주입된다.

- 따라서 클라이언트 입장에서는 원본과 동일하게 사용할 수 있다.(구분 못함)

- 싱글톤처럼 동작한다.

** 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 주의해서 사용해야 한다

*** 정말정말 꼭 필요한 곳에만 최소화해서 사용할 것! 무분별한 사용은 유지보수의 고단함을 낳을 수 있다!