[인프런]스프링 핵심원리 기본편_빈 스코프

빈 스코프

• 스프링 빈은 기본적으로 싱글톤 스코프로 생성된다. 이 덕분에 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 컨테이너가 종료될 때 까지 유지된다.
• 스코프는 빈이 존재할 수 있는 범위를 의미한다.

스프링은 다음과 같은 다양한 스코프를 지원한다.

싱글톤

• 기본 스코프이며 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.

프로토 타입

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

웹 관련 스코프

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

---

프로토타입 스코프

• 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다.
• 반면에 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 반환한다.
• 스프링 컨테이너에 요청할 때 마다 새로 생성된다.
• 종료 메서드가 호출되지 않는다.
• 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다. 종료 메서드 호출도 마찬가지이다.

---

빈 스코프는 @Scope("name") 를 사용해서 자동과 수동으로 지정할 수 있다.

컴포넌트 스캔 자동 등록

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

컴포넌트 스캔 수동 등록

@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
	return new HelloBean();
}

---

싱글톤 빈 요청

• 1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다.
• 2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다.
• 3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환한다.

---

프로토타입 빈 요청 1

• 1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
• 2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고 필요한 의존관계를 주입한다.

 

---

프로토타입 빈 요청 2

• 3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
• 4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

---

 

프로토타입 스코프와 싱글톤 빈을 함께 사용하면 문제가 발생한다. 그에 대한 내용을 아래에서 알아보자.

스프링 컨테이너에 프로토타입  빈 직접 요청1

• 1. 클라이언트 A는 스프링 컨테이너에 프로토타입 빈을 요청한다.
• 2. 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환한다.
• 3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면서 count() 필드를 +1 한다.
• 결과적으로 프로토타입 빈의 count는 1이 된다.

---

스프링 컨테이너에 프로토타입  빈 직접 요청2

• 1. 클라이언트 B는 스프링 컨테이너에 프로토타입 빈을 요청한다.
• 2. 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환한다.
• 3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면서 count() 필드를 +1 한다.
• 결과적으로 프로토타입 빈의 count는 1이 된다.

---

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

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

• 1. clientBean은 의존관계 자동주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.
• 2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean에 반환한다. 프로토타입 빈의 count 필드 값은 0이다.

이제 clientBean은 프로토타입 빈의 참조값을 필드 내부에 보관한다.

---

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

클라이언트 A는 clientBean을 스프링 컨테이너에 요청해서 받는다. 싱글톤이므로 항상 같은 clientBean가 반환된다.

• 3. 클라이언트 A는 clientBean.logic()을 호출한다.
• 4. clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가한다. 이로써 count 값은 1이 된다.

---

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

클라이언트 B는 clientBean을 스프링 컨테이너에 요청해서 받는다. 싱글톤이므로 항상 같은 clientBean가 반환된다.

이 때 clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다.

주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이다. (사용할 때 마다 생성되지 않는다.)

• 5. 클라이언트 B는 clientBean.logic()을 호출한다.
• 6. clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가한다. 이로써 count 값은 2가 된다.

---

문제 해결방안

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

---

ObjectFactory, ObjectProvider

• ObjectProvider : 지정할 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공한다.
• 과거에는 ObjectFactory가 있었는데, 여기에 편의 기능을 추가한 것이 ObjectProvider 이다.
• ObjectProvider 의 getObject() 를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (= DL)
• 스프링이 제공하는 기능을 사용하지만 기능이 단순하기에 단위테스트를 만들거나 mock 코드를 만들기 훨씬 쉬워진다.

ObjectFactory

• 기능이 단순하다.
• 별도의 라이브러리가 필요 없다.
• 스프링에 의존한다.

ObjectProvider

• ObjectFactory 를 상속한다.
• 옵션과 스트림 처리 등의 편의 기능이 많다.
• 별도의 라이브러리가 필요 없다.
• 스프링에 의존한다.

---

JSR-330 Provider

• javax.inject.Provider 라는 자바 표준을 사용한다.
• 이 방법을 사용하려면 javax.inject:javax.inject:1 라이브러리를 gradle에 추가해야 한다.
• provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.(= DL)
• 자바 표준이고 기능이 단순하여 단위테스트를 만들거나 mock 코드를 만들기 훨씬 쉬워진다.
• get() 메소드 하나로, 기능이 매우 단순하다.
• 별도의 라이브러리가 필요하다.
• 자바 표준이므로 스프링이 아닌 다른 라이브러리에서도 사용할 수 있다.

---

웹 스코프

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

request

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

session

• HTTP session과 동일한 생명주기를 가지는 스코프이다.

application

• ServletContext와 동일한 생명주기를 가지는 스코프이다.

websocket

• 웹 소켓과 동일한 생명주기를 가지는 스코프이다.

---

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

---

웹 스코프 개발

• 웹 스코프는 웹 환경에서만 동작하기에 웹 환경이 되도록 build.gradle에 아래 라이브러리를 추가해야 한다.
• 아래 라이브러리를 추가하면 스프링 부트는 내장 톰캣 서버를 활용해서 웹 서버와 스프링을 함께 실행시킨다.

implementation 'org.springframework.boot:spring-boot-starter-web'

• 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다.
• 이럴 때 쓰기 좋은것이 request 스코프이다.
• 공통 포맷 : [UUID][requestURL] {message}
• UUID : 전 세계에서 유일한 아이디 값

• @Scope(value = "request") 를 사용해서 request 스코프로 지정할 수 있다.
• 지정한 후에 해당 빈은 HTTP 요청 하나 당 생성되고 HTTP 요청이 끝나는 시점에 소멸된다.
• 이 빈이 생성되는 시점에 자동으로 @PostConstruct 초기화 메소드를 사용해서 uuid를 생성하고 저장한다.
• 생성된 uuid는 다른 HTTP 요청과 구분하기 위해 사용된다.
• 이 빈이 소멸되는 시점에 @PreDestroy 를 사용해서 종료 메시지를 남긴다.
• requestURL은 이 빈이 생성되는 시점에는 알 수 없으므로 외부에서 setter로 입력받는다.

---

@Provider

• 강의를 통해 코드 작성 후 실행하면 오류가 발생한다. 해당 오류는 request 범위와 관련이 있다.
• request 스코프는 요청이 들어와서 나갈때까지가 생존범위이다.
• 그런데 요청이 들어오지 않은 상태에서 실행하기에 오류가 발생한 것이다.
• 이를 해결하기 위해서는 Provider 를 사용하면 된다. 그 중에서 ObjectProvider 를 사용해보자.

---

ObjectProvider

• objectProvider 덕분에 ObjectProvider.getObject() 호출 시점까지 request scope 빈의 생성을 지연할 수 있다.
• ObjectProvider.getObject() 호출 시점에는 HTTP 요청이 진행중이므로 request 스코프 빈의 생성이 정상적으로 처리된다.
• ObjectProvider.getObject() 를 컨트롤러와 서비스에서 각각 따로 호출해도 동일한 HTTP 요청이면 같은 스프링 빈이 반환된다.

---

프록시

• @Scope("") 에서 proxyMode 옵션을 사용한다. 아래와 같이 작성한다.
• @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
• 이 때 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS, 적용 대상이 인터페이스면 INTERFACES를 선택한다.
• 이를 통해 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.
• 프록시 객체 덕분에 클라이언트는 싱글톤 빈을 사용하는 것처럼 편리하게 request scope를 할 수 있다.
• 어노테이션 설정 변경 만으로도 원본을 프록시 객체로 대체할 수 있다. 이는 다형성과 DI 컨테이너의 큰 장점이다.

---

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

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

---

가짜 프록시 객체

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

---

동작 과정

• CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
• 이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
• 가짜 프록시 객체는 실제 request scope와는 관계가 없다. 내부에 단순한 위임 로직만 있고 싱글톤 처럼 동작한다.
• 가짜 프록시 객체는 원본 클래스를 상속받아서 만들어졌기에 이 객체를 사용하는 클라이언트 입장에서는 원본인지 아닌지 상관없이 동일하게 사용할 수 있다.(= 다형성)

---

해당 글은 인프런 > 스프링 핵심 원리 기본편(김영한)강의를 참고하여 작성하였습니다.