[Spring] 스코프, 프록시

 

빈 생명주기 콜백

• 스프링을 통해 객체 초기화/종료작업을 진행하기
• 스프링 컨테이너 생성 > 스프링 빈 생성 > 의존관계 주입 > 초기화 콜백 > 사용 > 소멸전 콜백 > 스프링 종료
  • 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
  • 소멸전 콜백 : 빈이 소멸되기 직전에 호출
• 객체의 생성과 초기화를 분리해야 함
• 빈 생명주기 콜백 지원 : 인터페이스/메서드 지정/애노테이션

 

 

 

@PostConstruct, @PreDestory

• @PostConstruct : 의존성 주입이 이루어진 후 빈의 초기화를 수행하는 메서드
  • bean의 생명주기에서 오직 한번만 실행된다
  • 어플리케이션이 실행될 때 한번만!
• @PreDestory : 스프링 컨테이너에서 빈을 삭제 전, 해야할 작업을 수행 (마지막 소멸 단계에서. close() 하기 전.)
• 애노테이션을 사용해 빈 생명주기 콜백을 지원하자!
• 스프링이 아닌 다른 컨테이너에서도 동작함 (패키지명 javax.annotation.PostConstruct)
• 단점
  • 외부 라이브러리에선 적용못함
  • 외부 라이브러리를 초기화/종료해야 하면 @Bean 을 이용하자

 

 

빈 스코프

• @Scope
• 스프링 빈은 싱글톤 스코프(빈이 존재할수있는 범위)로 생성되기 때문에( = 기본값), 스프링 컨테이너의 시작과 함께 생성됨
  • @Component, @Service, @Repository 등으로 자동 스캔한 빈은 싱글톤 형태로 하나만 생성됨
  • 빈의 범위를 변경할 때, @Scope 를 사용한다
• 스프링이 지원하는 스코프
  • 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작~종료까지 유지되는 가장 넓은 범위의 스코프 (하나의 빈)
  • 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성, 의존관계 주입까지만 관여함 (매우 짧은 범위의 스코프)(요구가 있을시 새로운 빈을 만듬)
  • 웹 관련 스코프

//컴포넌트 스캔 자동 등록
@Scope("prototype")
@Component
public class HelloBean {}

//수동 등록
@Scope("prototype")
@Bean
PrototypeBean HelloBean () {
	return new HelloBean();
}

 

 

 

프로토타입 스코프

• 스프링 컨테이너가 싱글톤 스코프의 빈 조회 -> 항상 같은 인스턴스의 스프링 빈 반환
  • 스프링 컨테이너 생성 시점 -> 싱글톤 스코프의 초기화 메서드가 실행됨
• 스프링 컨테이너가 프로토타입 스코프 조회 -> 항상 새로운 인스턴스 생성 후 반환
  
  1. 스프링 컨테이너에 프로토 타입 스코프 빈 요청
  2. 스프링 컨테이너는 이 시점에 프로토타입 빈 생성, 필요한 의존관계 주입
  3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환
  4. 스프링 컨테이너에 같은 요청이 오면, 항상 새로운 프로토타입 빈을 생성 후 반환
• 프로토타입 빈의 특징
  • 스프링 컨테이너에 요청할 때마다 새로 생성됨
  • 종료 메서드가 호출되지 않음
  • 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 함

@Scope("singleton") //싱글톤 스코프 빈 조회하기

@Scope("prototype") //프로토타입 스코프 빈 조회하기

 

 

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

• 스프링 컨테이너 -> 프로토타입 스코프의 빈 요청 -> 새로운 객체 인스턴스 반환
  • 스프링은 일반적으로 싱글톤 빈을 사용. (싱글톤 빈이 프로토타입 빈을 사용하게 함)
  • 싱글톤 빈 => 생성시점에만 의존관계 주입 받음
  • 프로토타입 빈 => 주입시점뿐 (만 아니라 사용할때마다 새로 생성해서 사용하길 원할때는 어떡하지?)
• Provider 로 문제 해결(DL)
  • 매번 사용할 때 마다, 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하기
  • 프로토타입 사용 시 마다 스프링 컨테이너에 요청
    • 가장 간단한 방법이지만, 스프링 컨테이너에 종속적인 코드가 되고 단위테스트가 어려워짐
  • ObjectFactory, ObjectProvider
    • 보통 쓰는 것
    • 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 인터페이스
      • ObjectFactory : 과거의 것
      • ObjectProvider : ObjectFactory 에 편의기능 추가한 것
      • ObjectProvider의 getObject() 를 호출 -> 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.
  • JSR-330 Provider
    • 스프링이 아닌 다른 컨테이너에서도 사용해야 할 때 씀
    • javax.inject.Provider 라는 JSR-330 자바 표준 사용
    • javax.inject:javax.inject:1 라이브러리를 gradle에 추가해야함
    • get() 메서드 하나로 기능이 매우 단순함

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {

	//ObjectProvider 의 getObject 호출 => 내부에서 스프링 컨테이너를 통해 해당 빈을 찾아서 반환
	PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
	prototypeBean.addCount();
 	int count = prototypeBean.getCount();
 	return count;
}

 

 

 

웹 스코프

• 웹 환경에서만 동작
• Spring web 라이브러리를 추가해야 됨
• 프로토타입과 달리, 스프링이 해당 스코프의 종료시점까지 관리함 (종료메서드도 호출)

 

웹 스코프의 종류

• request : HTTP 요청당 하나의 빈 반환. 각각 HTTP마다 별도의 빈 인스턴스 생성/관리
• session : HTTP Session당 하나의 빈 반환.
• application : ServletContext 와 동일한 생명주기를 가지는 스코프
• websocket : 웹소켓과 동일한 생명주기를 가지는 스코프

 

 

request 스코프

• 동시에 여러 HTTP 요청이 왔을 때, 정확히 어떤 요청이 남긴 로그인지 구분하기 쉬움
  • 같은 스프링 빈을 호출할 때, 어디에서 요청한건지 구분할 수 있게 함
  • 이 애노테이션이 적용된 빈은 HTTP 요청 당 하나씩 생성됨
• @Scope(value = "request") : request 스코프 지정하기
  
  • HTTP 요청이 끝나는 시점에 소멸됨
  • 요청이 안오면 생성되지 않음
• ObjectProvider 사용해 HTTP 요청이 왔을때 빈 생성하기

//선언
private final ObjectProvider<MyLogger> myLoggerProvider;

 public void logic(String id) {
 	//해당 빈을 찾아서 (빈 생성 지연) -> 해당 빈 반환(새로운 빈 생성)
 	MyLogger myLogger = myLoggerProvider.getObject();
 	myLogger.log("service id = " + id);
 }

 

 

 

스코프와 프록시

• 싱글톤을 사용하는 것처럼 동작함 (싱글톤으로 착각하지 않게 주의 필요)
• 꼭 필요한 곳에서만 최소화해서 사용하기
• Provider을 사용하지 않아도 작동됨

프록시 방식

• TARGET_CLASS : 적용 대상이 클래스 일 때
• INTERFACES : 적용 대상이 인터페이스 일 때

//proxyMode = ScopedProxyMode.TARGET_CLASS 추가
//MyLogger을 상속받은 가짜 프록시 객체를 생성
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

 

구동방식

• CGLIB 라는 라이브러리로, 원본 클래스를 상속받은 가짜 프록시 객체를 만들어 주입함
• 가짜 프록시 객체이나, request 스코프의 진짜 요청해야하는 메서드를 호출해줌
  
  • 가짜 프록시 객체 내 -> 실제 요청이 오면 내부에서 실제 빈을 요청하는 위임 로직이 들어있음
  • provider 처럼 빈생성을 지연해서, 진짜 객체 조회 후 생성하는 목적이 비슷함