[Spring] 김영한 기본편_ 섹션 10. 빈 스코프

<출처 인프런>

8월 전에 다 끝내기로 한 계획,,,! 강의는 모두 들었지만 왜인지 블로그 작성은 미뤄졌다. 그래도 영상 다 들은게 어디냐며 약간의 위로와 함께 블로그 작성을 해보려한다. 코로나로 인해 체력이 박살난건지, 그냥 이미 박살난걸 내가 몰랐던 건지 알 수 없지만 위경련 터지며 길바닥에 주저앉는 인생이어도 오늘도 화이팅!! 모두들 화이팅!

 

🧸 

 

---

 

🧸 구조파악 레츠꼬우- 🧸

 • scope

ㄴ class :  SingletonTest, SingletonWithPrototypeTest1, PrototypeTest

 • web

ㄴ class :  LogDemoController, LogDemoService

• common

ㄴ class :  MyLogger

 

---

 

Q. 빈 스코프란?

A. 빈이 사용되어지는 범위이다.

 

 

✔️  SingletonTest

 

►  결과

 

지금까지 우리가 배운 것은 싱글톤 빈 스코프다. 싱글톤 빈 스코프는 싱글톤 빈이 시작되어 끝날때까지 유지된다. 또 같은 요청에 대해 같은 인스턴스 빈으로 반환한다.

 

 

 

 

---

 

 

 

✔️  PrototypeTest

 

@Scope("prototype")
static class PrototypeBean {

}

 

@Scope("prototype")

: 빈의 스코프를 프로토타입으로 설정한다. 

 

 

►  결과

프로토타입 빈의 인스턴스가 다르게 요청된 것을 볼 수 있다. 싱글톤 빈 스코프는 처음부터 끝까지 유지되지만 프로토타입은 의존관계 주입과 초기화(Prototype.init 2번 요청된 것을 보면)까지만 관여한다. 그렇기에 Predestroy 메서드는 실행되지 않는다. (현재 실행 결과에서 Prototype.destroy가 있지만, 따로 코드에 prototypeBean1.destroy();를 적어서 그런것이다.)

 

 

 

 

---

 

 

✔️  SingletonWithPrototypeTest1

 

►  프로토타입과 싱글톤을 함께 쓸 경우 생기는 문제점

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

 

코드를 살펴보면 싱글톤 클래스인 ClientBean 내부에 프로토타입 빈이 선언되었다. 모두가 알다시피 싱글톤 빈은 생성시점 딱 한 번 생성되고 그 생성된 것을 중복하여 사용하는 방식이다.(이미 할당된 인스턴스를 같은 빈을 사용할 때 마다 같은 인스턴스 할당) 그러니 그 내부에 함께하는 프로토타입도 본래의 특성이 아닌 싱글톤 빈을 따라가게 되는 것이다.

 

Q. 만약 같은 인스턴스가 계속 호출되는 프로토타입은 더이상 프로토타입이 아니고 싱글톤이라고 할 수 있나?

A. 맞다. 그 특성이 싱글톤이 되었으니, 더이상 프로토타입이 아니다.

 

 

 

 

►  주입 시점 차이

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

 

전 코드는 싱글톤 빈 내부에 프로토타입이 선언되었다. 현재 코드는 ApplicationContext를 이용해 프로토타입 빈을 따로 관리하고 있음을 알 수 있다. logic 메서드가 호출되면 ac(ApplicationContext)를 통해 프로토타입 빈을 매번 요청하게 된다. 

 

 

 

 

 

►  ObjectFactory

static class ClientBean {

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

 

ObjectProbvider

: 지정한 빈을 찾아 컨테이너에서 대신 찾아주는 DL 서비스를 제공한다. / 스프링에 의존적이다.

 

 

 

- ObjectProvider 출처

ObjectProvider (Spring Framework 6.1.13 API)

 

- ObjectFactory 출처

ObjectFactory (Spring Framework 6.1.13 API)

 

 

 

 

►  JSR-330 Provider

static class ClientBean {

    @Autowired
    private Provider<PrototypeBean> prototypeBeanProvider;

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

 

Provider< >

:  < > 안의 인스턴스를 제공하고 지연, 옵션, 의존적인 경우인 순환참조문제에 쓴다.

 

 

- Provider 출처

Provider (Jakarta EE 8 Specification APIs)

 

 

 

 

---

 

 

 

 

✔️  MyLogger

가짜 프록시를 이용하여 로그 요청을 위한 클래스

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

 

value

: 웹 스코프의 종류를 의미하며, 현재는 Http 요청 하나가 들어가고 나갈때 가지 유지되는 request로 되어있다.

 

 

ProxyMode

: GoF 다자인 패턴으로 해당 객체의 생성이나 초기화를 지연하거나, 접근을 제어할 때, 성능 최적화가 필요한 경우 사용한다.

 

ScopedProxyMode의 종류

- DEFAULT : 프록싱 없음
- NO : 프록싱 없음 (DEFAULT와 같음)
- INTERFACE : 인터페이스 기반으로 동적 프록싱 생성
- TARGET_CLASS : 대상 클래스 기반으로 CGLIB 프록시 생성
- SCOPED_PROXY INTERFACES : INTERFACE 혹은 TARGET_CLASS 중 하나를 나타내는 특별한 단축형 값이다.

 

 

고객이 서비스를 언제 요청할지 모른다. 거기다 

 

 

 

- ProxyMode  출처

ProxyMode in Spring Framework

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

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);
}

 

setter를 통해 requestURL을 받는다. 그리고 처음 Http 요청이 오면 @PostConstruct를 통해 uuid를 random으로 만들어 log로 보낸다.

 

 

Q. requestURL은 빈이 생성되는 시점을 알 수 없기 때문에 setter로 받는데 왜 생성시점을 모를까?

A. 현재 MyLogger의 코드를 살펴보면, requestURL을 생성하는 코드는 존재하지 않는다. 즉, 다른 클래스에서 받아온다는 것이다. 거기다 MyLogger은 request 스코프로 정의되어있다. 그렇다는건 Http의 요청이 들어오면 새로운 인스턴스가 생성되고, 그 후에 requestURL 값이 결정된다는 것이다. 이러한 이유로 requestURL 빈은 생성시점은 알 수 없다. 일단 요청이 있어야하는데 요청이 언제 올지 모르며 다른 클래스(서비스나 컨트롤러)에 requestURL을 생성하는 코드가 있기 때문이다.

 

 

 

 

---

 

 

 

 

✔️  LogDemoController

로거가 잘 작동되는지 테스트용 컨트롤러

 

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final MyLogger myLogger;

 

@ReqiredArgsConstructor (Lombok)

: 초기화 되지않은 final 필드나, @NonNull이 붙은 필드에 대해 생성자를 생성하며, @Autowired를 사용하지 않고 의존성을 주입한다.

 

 

LogDemoService와 MyLogger 의존관계를 주입해준다. private와 final로 선언한 이유는 읽거나 수정을 못하게 하기 위함이다. 외부에서 수정될 경우 코드에 문제가 생길 수 있기 때문이다.

 

 

 

- @ReqiredArgsConstructor 출처

@NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

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

 

@RequestMapping( )

: 들어온 요청을 특정 메서드와 매핑하기 위해 사용한다.

 

현재 코드에서는 @RequestMapping에 대해 괄호 안에 어떤 value값이나 method값을 작성하지 않았다. 그렇다는건 요청방식에 관계없이 url이 일치하는 요청을 처리한다. 그러면 ("log-demo")라고 적혀있으니, log-demo 경로로 들어온 Http 요청을 이 메서드가 처리한다는 의미가 된다.

 

 

@ResponseBody

: Http 응답을 처리할 때 사용하는 어노테이션, 응답 바디를 JSON, XML, 문자열 등으로 변환하여 클라이언트에게 반환할 때 사용된다.

 

 

getRequestURL

: 요청에 사용된 URL로 부터 URL 값을 리턴한다.

 

 

toString( )

: 문자열 그대로 반환한다.

 

HttpServletRequest는 클라이언트가 보낸 Http 요청을 담고 있다. 그렇다면 MyLogger에서 가짜 프록시를 만들도록 했으니, Http 요청이 들어오면 logDemo에서 HttpServletRequest에 가짜 프록시를 넣고 시작하게 된다. 그 후에 클라이언트가 요청한 URL 값을 가져와 문자열 그대로 반환하도록 한다. 그렇게되면 myLogger.set- 코드를 통해 MyLogger에서 URL 값이 출력된다.

 

 

 

- @RequestMapping 출처

Spring @RequestMapping이란? 작성방법, 예시

 

 

- @ResponseBody 출처

[Spring] @RequestBody / @ResponseBody 어노테이션 이란?

 

 

- getrequestURL 출처

request 객체 메소드 간단정리 및 getRequestURL()과 getRequestURI() 차이

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

 

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

 

"controller test"라는 메세지와 함께 myLogger에 있는 log를 메서드를 호출한다. 그 밑에 줄은 logDemoService에 logic에 "testId"라는 메세지와 함께 logic 메서드를 호출한다. retuen "OK"는 클라이언트에게 OK라는 응답을 반환한다.

 

 

 

 

 

---

 

 

 

 

✔️  LogDemoService

주어진 id와 함께 로그를 남기는 서비스 로직을 처리

 

private final MyLogger myLogger;

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

 

아까 LogDemoController에  코드 쪽에 logDemoService.logic("testId");가 있었다. testId를 logic 메서드에 보내라는 의미이다. 그러면 받은 메세지를 가지고 logic 메서드는 MyLogger에 있는 log메서드에 id를 보내게 된다. 그러면 log 메서드에 필요한 uuid와 URL 그리고 id가 모두 잘 출력되게 된다.

 

 

 

 

---

 

 

 

✔️  총정리

 이번에 배운 것은 프로토타입 스코프와 웹 스코프에 관한 것이었다. 프로토타입 스코프는 싱글톤 스코프와 다르게 인스턴스를 필요할 때 마다 새롭게 받아 쓴다는 점이 있었는데, 주로 싱글톤과 함께 쓰일 프로토타입 스코프엔 큰 문제접이 있었다. 싱글톤 내부에 프로토타입 스코프를 선언하게 되면 싱글톤 스코프의 처음부터 끝가지 유지되는 특성을 그대로 가져가 새로운 인스턴스를 가져오지 못하게 된다는 것이다. 그렇기에 그 부분을 주입시점을 다르게하거나, ObjectProvider를 사용하거나, JSR-330 Provider를 사용하는 방법을 배웠다. (하지만 사실상 쓸 일이 많이 없다는 것) 

 

 아마 웹스코프는 웹개발을 하며 실무적으로 필요한 내용일 듯 하다. 웹스코프를 개발하면서 문제점은 request 스코프 빈이 실제 고객의 요청이 없기 때문에 오류가 발생시킨다는 점이었다. 그렇기에 가짜 프록시를 사용하여 일단 있는 척을 한 뒤, 나중에 필요한 부분에서 실제 스코프 빈이 있는 곳을 향해 생성되도록 하는 것이었다. 

 

 마지막 장 정리가 생각보다 오래걸렸다. 막판에 코로나 + 위경련 + 추석 등 여러 일로 인해 천천히 정리하다 결국 내용을 까먹어 다시 강의를 들어 복습하며 정리하게 되었다. 2024년 9월 22일 아직 앞에 정리했던 강의들은 다시 정리하진 않았지만, 빠르게 복습하며 앞에 정리해둔 블로그들도 다시금 손을 볼 예정이다. 

 모두들 건강하길 바라며...🎃