docs: Bean Scope 정리 추가

younghwanKim/Bean Scope.md

@@ -0,0 +1,161 @@
+## 빈스코프란?
+
+빈스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.
+
+**스코프의 종류**
+
+- **싱글톤**: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프.
+- **프로토타입**: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프.
+- **웹 관련 스코프**
+    - **request**: 웹 요청이 들어오고 나갈 때까지 유지되는 스코프
+    - **session**: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
+    - **application:** 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프
+
+---
+
+## 프로토타입 스코프
+
+- **싱글톤 스코프의 빈을 조회**하면 스프링 컨테이너는 **항상 같은 인스턴스의 스프링 빈을 반환**
+- **프로토타입 스코프**를 스프링 컨테이너에 조회하면 **스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.**
+
+### 프로토타입 빈 요청
+
+1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
+2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다.
+3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
+4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.
+
+### 정리
+
+여기서 핵심은 **스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다는 것이다.**
+
+프로토타입 빈을 관리할 책임은 빈을 받은 클라이언트에 있다. 그래서 @PreDestroy같은 종료 메소드가 호출되지 않는다.
+
+### 싱글톤 빈과 프로토타입 빈 차이점
+
+- **싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행**되지만, **프로토 타입 스코프의 빈은 스프링 컨테이너에서 조회할 때 생성**되고, 초**기화 메서드도 실행**된다.
+- 프로토타입 빈은 n번째 조회할 때마다 새로운 빈이 생성되므로, 초기화도 n번 실행된다.
+- 싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 컨테이너가 종료될 때 빈의 종료 메서드가 실행, 하지만 프로토타입 빈은 컨테이너가 의존관계 주입 그리고 초기화까지만 관여하고 관여하지 않는다. 따라서 프로토 타입 빈은 컨테이너가 종료될 때 `@PreDestroy` 같은 종료 메서드가 전혀 실행되지 않는다.
+
+### 프로토타입 빈의 특징 정리
+
+- 스프링 컨테이너에 요청할 때 마다 새로 생성된다.
+- 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.
+- 종료 메서드가 호출되지 않는다.
+- 그래서 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다. 종료 메서드에 대한 호출도 클라이언트가 직접 해야한다.
+
+---
+
+## 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점
+
+프로토타입 스코프의 스프링 빈을 싱글톤 빈과 함께 사용하게 되면 의도한대로 동작하지 않고 문제가 발생한다. 이에 대해 알아보고 해결책에 대해 학습하자.
+
+### 문제 발생 케이스
+
+- 싱글톤 스프링 빈 내부에 의존관계로 주입되는 스프링 빈이 프로토타입인 경우
+    - PrototypeBean은 프로토타입 스코프지만 clientBean은 싱글톤 스코프이기 때문에, 싱글톤 빈에서 프로토타입 빈을 사용함.
+    - 싱글톤 빈의 스코프는 스프링 컨테이너와 같은데, 프로토타입 스코프의 스프링 빈이 새로 생성되는 했지만 싱글톤 빈과 함께 사용되기 때문에 계속 유지된다.
+    - 그래서 빈을 2회 요청하지만 동일한 프로토타입 빈을 사용하게 되어 count는 1이 아닌 2가 된다.
+
+### 결론
+
+싱글톤과 프로토타입 빈을 같이 사용하면, 프로토타입 빈은 의존관계 주입할 때 한번 생성되며, 프로토타입 빈을 요청받을 때마다 주입당한 프로토타입 빈을 전달한다.
+
+프로토타입 빈을 새로 생성하고 싶으면, `application` 을 주입하면 된다.
+
+---
+
+## 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결
+
+- 위에 결론에서 말했다시피 `application` 을 주입해서 `ac.getBean()` 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
+- 의존관계를 외부에서 주입(DI) 받는게 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup(DL) 의존관계 조회(탐색) 이라한다.
+- 그리고 이렇게 생성하면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워진다.
+
+### ObjectFactory, ObjectProvider
+
+지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 바로 `ObjectProvider` 이다. 예전에는 `ObjectFactory` 가 있었는데, 여기에 편의 기능을 추가해서 `ObjectProvider` 가 만들어졌다.
+
+### ObjectFactory, ObjectProvider
+
+```java
+@Autowired
+private ObjectProvider<PrototypeBean> prototypeBeanProvider;
+
+public int logic() {
+   PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
+   prototypeBean.addCount();
+   int count = prototypeBean.getCount();
+   return count;
+}
+```
+
+- 실행해보면 `prototypeBeanProvider.getObject();` 을 통해서 항상 새로운 프로토타입 빈이 생성됨
+- `ObjectProvider` 의 `getObject()` 를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 변환한다.**(DL)**
+- `ObjectProvider` 는 지금 딱 필요한 DL 정도의 기능만 제공한다.
+
+### 특징
+
+- ObjectFactory: 기능이 단순, 별도의 라이브러리 필요 없음, 스프링에 의존
+- ObjectProvider: ObjectFactory 상속, 옵션, 스트림 처리등 편의 기능이 많고, 별도의 라이브러리 필요 없음, 스프링에 의존
+
+### Provider
+
+```java
+@Autowired
+private Provider<PrototypeBean> provider;
+public int logic() {
+   PrototypeBean prototypeBean = provider.get();
+   prototypeBean.addCount();
+   int count = prototypeBean.getCount();
+   return count;
+}
+```
+
+- `provider` 의 `get()` 을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환
+- 실행해보면 `provider.get();` 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
+- 자바 표준이고, 기능이 단순해 단위테스트를 만들거나 mock코드를 만들기 쉬움.
+- `Provider` 는 지금 딱 필요한 DL 정도의 기능만 제공.
+
+### 정리
+
+- 프로토타입 빈은 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다. 그런데 실무에서 웹을 개발하면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있어 사용하는 일은 드물다.
+- `ObjectProvider` ,JSR330 Provider등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용.
+
+---
+
+## 웹 스코프
+
+### 특징
+
+- 웹 스코프는 당연히 웹 환경에서만 동작
+- 웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리. ⇒ 종료 메서드가 호출
+
+### 종류
+
+- **request:** HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈인스턴스가 생성되고, 관리된다.
+- **session:** HTTP Session과 동일한 생명주기를 가지는 스코프
+- **application:** 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프
+- **websocket:** 웹 소켓과 동일한 생명주기를 가지는 스코프
+
+---
+
+### 프록시 동작 원리
+
+**CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.**
+
+- `@Scope` 의 `proxyMode = ScopedProxyMode.TARGET_CLASS` 를 설정하면 스프링 컨테이너는 CGLIB라는 바이트 코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성, 주입.
+- 이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
+- 가짜 프록시 객체는 실제 request scope의 진짜 `myLogger.logic()` 를 호출.
+- 가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다. (다형성)
+
+### 특징
+
+- 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
+- 사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 **지연처리 한다는 점**이다.
+- 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.
+- 꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다
+
+### 주의점
+
+- 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
+- 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.