[스프링 핵심 원리 - 기본편] #9. 빈 스코프 (2)

[seyxxn]

9_빈 스코프

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

• 프로토타입 스코프를 싱글톤 빈과 함께 사용할 때 Provider을 사용해서 문제를 해결함
• 어떻게하면 항상 새로운 프로토타입 빈을 생성할까?

스프링 컨테이너에 요청

@Autowired
private ApplicationContext ac;
public int logic() {
    PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

• 가장 간단한 방법
• 싱글톤 빈이 프로토타입을 사용할 때 마다 스프링 컨테이너에 새로 요청하는 것
• @Autowired로 로직을 호출할 때 마다, 컨테이너에게 새로 요청하여 받음
  • 이렇게하면 항상 새로 생성하고 동작하게 됨
• ac.getBean()을 통해 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있음
• 의존관계를 외부에서 주입(DI)받는 게 아니라 직접 필요한 의존관계를 찾는 것을 Dependency Lookup(DL) 의존관계 조회(탐색)이라 함
  • 그런데, 이렇게 스프링의 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워짐
  • 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는 DL(의존관계 조회) 정도의 기능만 제공하는 무언가가 필요 => 스프링에게 이러한 기능이 있음

ObjectFactory, ObjectProvider

• 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 바로 ObjectProvider
• ObjectFactory는 과거에 쓰던 것으로, 편의기능들이 추가되어 ObjectProvicer가 만들어짐

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
    PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

• prototypeBeanProvider.getObject()을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있음

• ObejctProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환함. 찾아주는 기능만 제공해주는 것임 -> DL

JSR-330 Provider

• jakarta.inject.Provider 사용

🚨 스프링 부트 3.0부터 발생하는 문제

jakarta.inject.Provider로 변경

// build.gradle
//implementation 'javax.inject:javax.inject:1' //제거
implementation 'jakarta.inject:jakarta.inject-api:2.0.1' //추가

// 소스 코드
//import javax.inject.Provider; //제거
import jakarta.inject.Provider; //추가

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

• provider.get()을 통해 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있음
• provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환(DL)

정리

• 프로토타입 빈을 언제 사용할까?
  • 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 됨
  • 실무에서 웹 애플리케이션을 개발해보면 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드묾

웹 스코프

• 위에서 배웠던 것

  • 싱글톤 : 스프링 컨테이너의 시작과 끝까지 함꼐하는 매우 긴 스코프
  • 프토로타입 : 생성과 의존관계 주입, 초기화까지만 진행되는 특별한 스코트

• 웹 스코프

  • 웹 환경에서만 동작
  • 프로토타입과는 다르게 스프리잉 해당 스코프의 종료시점까지 관리
  • 따라서 종료 메서드가 호출됨

• 웹 스코프의 종류

  • request : HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리됨
  • session : HTTP Session과 동일한 생명주기를 가지는 스코프
  • application : 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프
  • websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프

HTTP request 요청 당 각각 할당되는 request 스코프

• 클라이언트 A와 B가 완전히 동일한 시간에 요청을 했다고 가정해보자
• 이때, 각각 다른 인스턴스가 할당 됨
• 각각의 request 요청에 따른 각각 다른 스프링빈이 생성되어 호출
• 프로토타입과 다른점
  • 프로토타입은 요청할때마다 생성되었다면,
  • request 스코프는 HTTP request에 요청이 들어오고 나갈 때까지의 라이프사이클 동안은 무조건 같은 것이 관리가 됨
  • 클라이언트 a가 요청을 하면 a전용 스프링 빈이 만들어져서 운영이 되다가, a가 요청이 응답이 나가면 destroy 되는 방식

request 스코프 예제 만들기

웹 환경 추가

웹 스코프는 웹 환경에서만 동작하기 때문에 web 환경이 동작하도록 라이브러리 추가

//web 라이브러리 추가
implementation 'org.springframework.boot:spring-boot-starter-web'

request 스코프 예제 개발

• 동시에 여러 http요청이 오면 구분이 어려움
• 로그가 남도록 request 스코프를 이용하여 추가 기능을 개발해보자

[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

• 위 처럼 같은 리퀘스트인 경우에는 같은 uuid가 찍히도록 개발함

• MyLogger

  @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() {
          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 요청 당 하나씩 생성되고, HTTP 요청이 끝나는 시점에 소멸됨
  • 이 빈이 생성되는 시점에 자동으로 @PostConstruct 초기화 메서드를 사용해서 uuid를 생성해서 저장해둠. 이 빈은 HTTP 요청 당 하나씩 생성되므로, uuid를 저장해주면 다른 HTTP 요청과 구분할 수 있음
  • 이 빈이 소멸되는 시점에 @PreDestroy를 사용해서 종료 메세지를 남김
  • requestURL은 이 빈이 생성되는 시점에는 알 수 없으므로, 외부에서 setter로 입력받음

• LogDemoController

  @Controller
  @RequiredArgsConstructor
  public class LogDemoController {
      private final LogDemoService 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을 받음
    • requestURL 값 : http://localhost:8080/log-demo
  • 이렇게 받은 requestURL 값을 myLogger에 저장해둠. myLogger는 HTTP 요청 당 각각 구분되므로 다른 HTTP 요청때문에 값이 섞이는 걱정은 안해도 됨
  • 컨트롤러에서 controller test 라는 로그를 남김

• LogDemoService

  @Service
  @RequiredArgsConstructor
  public class LogDemoService {
      private final MyLogger myLogger;
  
      public void logic(String id) {
          myLogger.log("service id = " + id);
      }
  }

  • 비즈니스 로직이 있는 서비스 계층에서도 로그를 출력해보자
  • 만약, request scope를 사용하지 않고 파라미터로 이 모든 정보를 서비스 계층에 넘긴다면, 파라미터가 많아서 지저분해짐. 더 문제는 requestURL 같은 웹 관련 정보가 웹과 관련없는 서비스 계층까지 넘어가게 됨. 웹과 관련된 부분은 컨트롤러까지만 사용해야 함. 서비스 계층은 웹 기술에 종속되지 않고, 가급적 순수하게 유지하는 것이 유지보수 관점에서 좋음
  • requeset scope의 MyLogger 덕분에 이런 부분을 파라미터로 넘기지 않고, myLogger의 멤버변수에 저장해서 코드와 계층을 깔끔하게 유지할 수 있음

오류 발생

출력이 기대대로 되지 않고, 애플리케이션 실행 시점에 오류 발생

• 오류 발생 이유
  • 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되지 않음. 이 빈은 실제 고객의 요청이 와야 생성할 수 있음.
• 결국, 스프링 컨테이너에게 스프링 빈을 요청하는 단계를 의존관계주입이 아니라 실제 고객의 요청이 왔을 때로 뒤로 지연시켜야 함
• 프로바이더를 써서 해결해야함

스코프와 Provider

• 간단한 해결방법, 앞서배운 Provider를 사용하자 (ObjectProvider)

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

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

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

• ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있음
• ObjectProvider.getObject()를 호출하는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상처리됨
• ObejectProvider.getObject()를 LogDemoController, LogDemoService에서 각각 한번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환됨
• 동시에 여러요청이 온다 하더라도 요청마다 각각 객체를 따로 관리해준다는 것이 핵심

스코프와 프록시

프록시 방법 적용

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

• proxyMode = ScopedProxyMode.TARGET_CLASS 추가
  • 적용 대상이 클래스이면 TARGEL_CLASS
  • 적용 대상이 인터페이스면 INTERFACES
• 이렇게하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관없이 가짜 프록시 클래스를 다른 빈에 미리 주입해둘 수 있음

웹 스코프와 프록시 동작 원리

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

• @Scope의 proxyMode = ScopedProxyMode.TARGET_CLASS를 설정하면 스프링 컨테이너는 CGLIB라는 바이트 코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성함
• 결과를 확인해보면 순수한 MyLogger 클래스가 아니라 MyLogger$$EnhancerBySpringCGLIB이라는 클래스로 만들어진 객체가 대신 등록된 것을 확인할 수 있음
• 그리고 스프링 컨테이너에 myLogger라는 이름으로 진짜 대신에 가짜 프록시 객체를 등록
• ac.getBean("myLogger", MyLogger.class)로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있음

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

• 가짜 프록시 객체는 내부에 진짜 MyLogger를 찾는 방법을 알고 있음
• 클라이언트가 myLogger.log()를 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것임
• 가짜 프록시 객체는 request 스코프의 진짜 myLogger.log()를 호출함
• 가짜 프록시 객체는 원본 클래스를 상속받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게 동일하게 사용할 수 있음 (다형성)

동작 정리

• CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입
• 이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있음
• 가짜 프록시 객체는 실제 request scope와는 관계 없음. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤처럼 동작

특징 정리

• 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있음
• 사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리한다는 점
• 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있음. 이것이 다형성과 DI 컨테이너가 가진 큰 장점
• 꼭 웹 스코프가 아니어도 프록시 사용가능

[Pracrobo]

겁나 빠르시네요,,, 빨리 쫓아가겠습니다,.,