빈 스코프

빈 스코프란?

우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지된다고 학습했다.

그 이유는 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 빈이 존재할 수 있는 범위를 뜻한다.

 

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

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

- 웹 관련 스코프

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

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

 

빈 스코프 지정하는 방법은 @Scope 어노테이션을 적용하면 된다.

 

 

프로토타입 스코프

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

하지만 프로토타입 스코프의 빈을 스프링 컨테이너에 조회하면 항상 새로운 인스턴스를 반환한다.

 

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

- 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성 후 필요한 의존관계 주입

- 스프링 컨테이너는 클라이언트에게 생성한 프로토타입 빈을 반환

- 이후에 같은 요청이 들어오면 새로운 프로토타입 빈을 생성해서 반환

핵심은 빈 생성, 의존관계 주입, 초기화까지만 처리한다는 점이다.

 

 

public class PrototypeTest {

    @Test
    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");
        }
    }
}

새로운 빈이 init 되는것과 destroy가 호출되지 않는것을 확인할 수 있다.

종료 메서드가 필요하다면 prototypeBean1.destory 처럼 직접 메서드를 호출해야 한다.

 

 

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

이번에는 clientBean이라는 싱글톤 빈이 의존관계 주입을 통해서 프로토타입 빈을 주입받아서 사용하는 예를 들어보자

@Test
void singletonClientUsePrototype() {
    AnnotationConfigApplicationContext ac =
            new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);

    ClientBean clientBean1 = ac.getBean(ClientBean.class);
    int count1 = clientBean1.logic();
    assertThat(count1).isEqualTo(1);

    ClientBean clientBean2 = ac.getBean(ClientBean.class);
    int count2 = clientBean2.logic();
    assertThat(count2).isEqualTo(2);

}

static class ClientBean {
    private final PrototypeBean prototypeBean; // 생성 시점에 주입

    ClientBean(PrototypeBean prototypeBean) {
        this.prototypeBean = prototypeBean;
    }

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

 

 

 

clientBean은 싱글톤이므로 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.

- clientBean은 의존관계 자동주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.

- 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean에 반환한다. 이 때 프로토타입 빈의 count = 0 

- 이제 clientBean은 프로토타입 빈을 내부 필드에 보관한다. (정확히는 참조값을 보관)

 

처음 클라이언트 A가 logic()을 호출한다. 이 때 count++가 발생해 1이 되고, 다음 클라이언트B가 logic을 호출하면 count는 2가된다.

그 이유는 프로토타입 빈이라고 하더라도 싱글톤에서 생성시점에 주입이 이미 끝났기 때문에, 항상 같은 프로토타입 빈이 반환되는 것이다.

호출한다고 해서 또 다른 프로토타입 빈이 생성 되는게 아니다.

 

참고로 여러 빈에서 같은 프로토타입 빈을 주입받으면 각각 다른 프로토 타입 빈이 생성된다.

 

이렇게 됐을 경우에, 굳이 프로토타입 빈을 싱글톤에서 사용할 필요가 없다. 왜냐면 우리는 프로토타입 빈을 사용하는 이유는

요청할때마다 다른 프로토타입 빈을 원하는 것인데, 이렇게 되면 싱글톤을 쓰는거랑 다를게 없기 때문이다.

 

 

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

싱글톤 빈과 프로토타입 빈을 함께 사용할 때, 어떻게 하면 사용할 때마다 항상 새로운 프로토타입 빈을 생성할 수 있을까?

 

요점부터 정리

- @Scope("prototype"): 요청할 때마다 새로운 객체를 만듬

- @Scope("singleton"): 스프링 컨테이너에 단 하나만 존재

문제는 싱글톤 빈 안에 프로토타입 빈을 주입하면, 프로토타입 빈이 딱 한 번만 생성돼서 고정됨

해결방법은 필요할 때마다 꺼내쓰는 방법을 쓰자 -> DL (Dependency LookUp) 이라고 함.

 

방법1. ApplicationContext 직접 주입 받아서 getBean() 호출

@Autowired
private ApplicationContext ac;

public int logic() {
    PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class); // ★ 매번 새로 생성됨
    prototypeBean.addCount();
    return prototypeBean.getCount();
}

 

이렇게 직접 주입 받으면 매번 새로운 PrototypeBean이 가능하다.

단점은 스프링 컨테이너에 (ApplicationContext)에 너무 의존하기 때문에, 테스트하기 어렵다.

 

방법2. ObjectProvider 사용 (스프링 제공)

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {
    PrototypeBean prototypeBean = prototypeBeanProvider.getObject(); // ★ 새로 생성됨
    prototypeBean.addCount();
    return prototypeBean.getCount();
}

 

ObjectProvider는 간편한 DL 도구이다.

내부적으로 ApplicationContext.getBean()과 비슷하게 동작함.

스프링 기능이지만, 테스트하기 편하고 깔끔하다는게 장점이다.

 

방법3. Provider 사용 (자바 표준 / JSR-330)

@Autowired
private Provider<PrototypeBean> provider;

public int logic() {
    PrototypeBean prototypeBean = provider.get(); // ★ 새로 생성됨
    prototypeBean.addCount();
    return prototypeBean.getCount();
}

 

Provider는 자바 표준(JSR-330)이고 스프링 전용이 아니다. 그러므로 다른 프레임 워크에서 쓸 수 있다.

그리고 테스트하기도 쉽다.

 

ObjectProvider나 Provider를 쓰면, 싱글톤 빈 안에서도 매번 새 프로토타입 빈을 얻을 수 있다.

사용자 요청마다 매번 새로운 작업 객체를 만들어야 한다면 이 방식이 유용한데, 사실 이 방법은 실무에서 쓸 일은 잘 없다.

싱글톤으로도 충분히 해결할 수 있기 때문이다.

 

 

웹 스코프

웹 스코프의 특징

- 웹 스코프는 웹 환경에서만 동작한다.

- 웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료 시점까지 관리한다. (종료 메서드가 호출된다.)

 

웹 스코프 종류

request, session, application, websocket등이 있는데, 이번엔 request만 알아보려고 한다.

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

 

 

request 스코프

웹 스코프는 웹 환경에만 동작하므로 web 라이브러리를 build.gradle에 추가해주어야 한다.

 

[d06b992f...] request scope bean create

[d06b992f...][http://localhost:8080/log-demo] controller test

[d06b992f...][http://localhost:8080/log-demo] service id = testId

[d06b992f...] request scope bean close

 

우리는 이런 로그가 남도록 request 스코프를 활용해서 추가기능을 개발할 것이다.

 

import java.util.UUID;

@Component
@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() {
        String 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);
    }
}

 

로그를 출력하기 위한 MyLogger 클래스이다.

- @Scope(value = "request")  를 사용해서 request 스코프로 지정했다. 이제 이 빈은 HTTP 요청 당 하나씩 생성되고 끝나는 시점에 소멸된다.

- 이 빈이 생성되는 시점에 자동으로 @PostConstruct 초기화 메서드를 사용해서 uuid를 생성하고 저장해둔다. 이 빈은 요청마다 하나씩 생성되므로 uuid를 저장해두면 다른 HTTP 요청과 구분할 수 있다.

- 빈이 소멸되는 시점에 @Destroy를 사용해서 종료 메세지를 남긴다.

- requestURL은 이 빈이 생성되는 시점에는 알 수 없으므로, 외부에서 setter로 입력 받는다.

 

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoServiced logDemoService;
    private final MyLogger myLogger;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);

        myLogger.log("controller test");
        logDemoService.logic("testID");
        return "OK";
    }
}

 

로그가 잘 작동하는지 테스트용 컨트롤러이다.

HttpServletRequest를 통해서 요청 URL을 받았다. (http://localhost:8080/log-demo)

이렇게 받은 값을 myLogger에 저장해둔다. HTTP 요청 당 각각 구분되므로 값이 섞일일은 없다.

그 후에 컨트롤러에서 controller test라는 로그를 남긴다.

 

@Service
@RequiredArgsConstructor
public class LogDemoServiced {

    private final MyLogger myLogger;

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

 

서비스 계층에서도 로그를 출력해보자

여기서 중요한 점은 request scope를 사용하지 않고 파라미터로 모든 정보를 서비스 계층에 넘긴다면 생기는 문제

- 파라미터가 많아서 지저분해짐

- requestURL같은 웹과 관련된 정보가 웹과 관련없는 서비스 계층까지 넘어가게 된다.

- 웹과 관련된 부분은 컨트롤러까지 허용해야한다. 서비스 계층은 웹 기술에 종속되지 않고, 순수하게 유지하는것이 유지보수에 좋다.

 

이렇게 실행 했을 때 기대와 다르게 애플리케이션 실행시점에 오류가 발생한다.

MyLogger는 request scope 빈인데, 싱글톤 빈인 LogDemoService 또는 LogDemoController에 주입하려다 실패한다.

그 이유는 myLogger는 HTTP요청 (request)가 있어야만 활성화 되는데, 서로 시점이 맞지 않는다.

 

스프링 컨텍스트 초기화 시점 (요청 전 시점)에는 request scope가 아직 활성화 되지 않았기 때문이다.

이 때 이전에 배운 Provider를 사용하면 해결할 수 있다.

 

왜 안되는지 자세한 설명

- @RequestScope는 HTTP 요청이 시작된 시점에만 유효한 빈을 생성함.

@RequestScope으로 선언한 MyLogger는 프록시 객체가 생성되고, 이 프록시는 실제 HTTP요청이 들어와야 진짜 객체 (MyLogger)를 내부적으로 연결해주게 되어있음

그런데!

private final MyLogger myLogger;

 

이런식으로 필드에 직접 주입해버리면 HTTP 요청이 오기도 전에 프록시 객체가 주입된 상태가 되어버리는 것.

 

 

스코프 Provider 사용 예제

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoServiced 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";
    }
}

 

스프링 Provider를 사용한 코드

이 시점에 스프링은 "이제 진짜 요청 스코프의 MyLogger를 꺼내야한다"라고 판단 후 실제 요청과 연결된 진짜 MyLogger 인스턴스를 만들어 리턴해주게 된다. 즉 진짜 사용할 타이밍에 가져오기 때문에 문제가 발생하지 않는다!

 

 

스코프와 프록시

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

 

@Scope 어노테이션에 proxyMode를 추가했다.

적용 대상이 클래스면 TARGET_CLASS, 인터페이스면 INTERFACES를 선택하자.

이렇게 하게 되면 MyLogger의 가짜 프록시 클래스를 만들어 두고 HTTP request와 상관없이 가짜 프록시 클래스를

다른 빈에 미리 주입해 둘 수 있다.

 

이렇게 실행한 후 ObjectProvider를 사용하지 않는 코드로 다시 변경했다.

 

실행 결과 Provider를 사용하지 않아도 정상적으로 작동되는 모습을 볼 수 있다.

다른 점이 있다면 myLogger의 getClass를 찍어본 결과 CGLIB을 통해 내 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입했다.

(CGLIB 관련내용은 이전 포스트 참고)

 

스프링 컨테이너엔 myLogger라는 이름으로 진짜 대신 가짜 프록시 객체를 등록이 되었다.

가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

- 가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고있다.
- 클라이언트가 호출한 myLogger.log()는 사실 가짜 프록시 객체의 메서드를 호출한 것이다.

- 가짜 프록시 객체는 request scope의 진짜 myLogger.log()를 호출한다.

- 가짜 프록시 객체는 원본 클래스를 상속받아서 만들어졌기 때문에 클라이언트 입장에선 진짜인지 가짜인지 알 바 아니다. (다형성)

 

이 코드의 좋은점은 단지 어노테이션 설정 변경만드로 원본 객체를 프록시 객체로 대체할 수 있다는 점이다.

이것이 바로 다형성과 DI컨테이너의 큰 장점이기도 하다.

 

주의할 점은 싱글톤처럼 작동하는것으로 보일 수 있기 때문에 (내부 인스턴스는 요청마다 다르다는걸 잊지말기) 조심해서 사용해야한다.

그리고 이런 특별한 scope는 필요한곳에만 최소화해서 사용할 것. 유지보수가 어려워진다.

 

요약

스코프 (scope)

- 빈이 생성되고 유지되는 생명주기 . 기본 스코프는 singleton이다.

 

프로토타입 스코프

- ac.getBean()으로 요청할 때마다 새 인스턴스 반환. 초기화 (@PostConstruct)는 되지만 종료 (@PreDestroy)는 안됨.

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

- 싱글톤 빈에 프로토타입 빈을 의존성 주입하면 딱 한번만 주입 -> 같은 인스턴스가 사용되므로 쓰나마나

 

 해결방법 

-필요한 시점에 프로토타입 생성 (DL)

- ObjectProvider (스프링 제공, 스프링 의존적), Provider(자바 표준, 스프링 비 의존적)

 

웹 스코프

- 웹 환경에서만 동작

- 빈 생성과 소멸 모두 스프링이 관리

- 종료시점에 @PreDestory 호출됨

 

request 스코프

- HTTP 요청마다 새로운 인스턴스 생성

- uuid, requestURL 등 요청 단위 데이터 저장 가능

- 로그 출력용으로 활용 가능

 

싱글톤 빈에 request 스코프 빈 주입시 문제

- HTTP요청이 있어야만 활성화 되므로 사용불가, ProxyMode나 Provider 사용