본문 바로가기

SpringFramework Core - I. IoC 컨테이너/5. Bean Scopes

5.2. 프로토타입 Scope

원문: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-factory-scopes-prototype

 

 

싱글턴이 아닌 프로토타입 scope는 해당 bean에 대한 요청이 있을 때마다 새로운 bean의 인스턴스를 생성하도록 한다. 즉, bean이 다른 bean으로 주입되거나 컨테이너에 getBean() 메소드를 호출함으로써 bean을 요청하게 된다. 규칙상, 모든 stateful한 bean들에는 프로토타입 scope를 써야하고, stateless한 bean들에는 싱글턴 bean을 써야한다.

 

다음 다이어그램은 스프링 프로토타입 scope를 보여준다.

(데이터 접근 객체(DAO)는 프로토타입으로 설정되지 않는다. 왜냐하면 전형적인 DAO는 conversational state를 유지하지 않기 때문이다. 단지 싱글톤 다이어그램을 또 쓰고 싶었을 뿐이다...)

 

다음 예시는 XML에서 프로토타입 bean을 정의하는 것이다.

<bean id="accountService" class="com.something.DefaultAccountService" scope="prototype" />

다른 scope들과는 대조적으로, 스프링은 프로토타입 bean의 라이프사이클을 전부 관리하지는 않는다. 컨테이너는 프로토 타입 객체를 인스턴스화하고 설정도 하지만 조립해서 클라이언트에게 건네주고는 더이상 그 인스턴스에 대해 신경쓰지 않는다. 그래서 scope와 상관없이 모든 객체에서는 '초기화 라이프사이클 콜백 메소드'가 호출되지만, 프로토타입의 경우에는 설정된 소멸 라이프사이클 콜백들이 호출되지 않는다. 클라이언트 코드가 반드시 프로토타입 객체를 없애서, 프로토타입 객체가 사용하던 리소스들을 놔주어야 한다. 프로토타입 bean들이 사용하는 리소스를 풀어주기 위해서 스프링 컨테이너는 커스텀한 bean post-processor를 사용한다. 이 processor는 청소가 필요한 bean들의 참조를 가지고 있다.

 

어떤 면에서 프로토타입 bean에 대한 스프링 컨테이너의 역할은 자바의 new 생성자의 대체같기도 하다. 이런 특징을 갖는 모든 라이프사이클에 대한 관리는 클라이언트에 의해 이루어져야 한다. (스프링 컨테이너에 속한 bean의 라이프사이클에 대해 자세히 알고 싶다면, 라이프사이클 콜백을 참고하라)