출처 : 빈 스코프 설명
출처 : seolhun.github.io/contents/
- 스프링 레거시 프로젝트
- 파일 구조 : MainClass.java / Student.java / applicationCTX.xml
Spring Bean Scope
- Bean 정의는 실제 bean 객체를 생성하는 방식을 정의하는 것이다. Class와 마찬가지로 하나의 Bean 정의에 해당하는 다수의 객체가 생성될 수 있다.
- Bean 정의를 통해 객체에 다양한 종속성 및 설정값을 주입할 수 있을 뿐 아니라, 객체의 범위(scope)를 정의할 수 있다. Spring Framework는 5가지 scope을 제공한다
(그 중 3가지는 web-aware ApplicationContext를 사용할 때 이용할 수 있다).
- 실습 코드들로 설명하겠습니다.
여기서부터는 제가 이해하고 직접 실습한 내용들로 구성되어 있습니다. (참고 사이트를 이용해서 작성..)
범위 내용
- 설명에 기준이될 코드 사진입니다. (singleton과 prototype만)
- Student 데이터 클래스를 생성
- Student 클래스를 이용해 student1 과 student2의 객체를 생성하였습니다.
- Singleton Scope
- bean이 singleton인 경우 하나의 공유 객체만 관리된다고 합니다.
- scope를 지정해놓지 않으면 deault(기본값)은 singleton이 됩니다.
- setter를 이용하여 값을 초기화 해줬지만 scope로 인해 공유받은 객체는 student1 하나뿐만 인식이 되는거 같습니다.
- 결국 Student stuent1 이든 Student student2든 하나의 객체만 관리되어 객체를 여러개 생성해도 객체 '하나'로만 범위가 지정됩니다. (student3, student4...... -> student1)
- prototype Scope
- benadl prototype인 경우 bean은 필요한 매 순간 새로운 bean 객체가 생성된다고 합니다.
- 기준이 되는 코드를 보시면 stuent1 과 student2를 생성했습니다. 이것을 singleton에서는 하나의 객체만 인정해줬는데 prototype은 두 개의 객체를 인정해준다는 겁니다.
- 기준 코드의 set문 다음 출력문을 보시면 singleton에서는 student1의 객체를 출력해서 결과물이 달라도 같다라고 판별해줬지만 prototype 서로 독립적인것을 인정해서 각각의 객체를 출력해 줄 수 있는것 같습니다.
- student2.getName으로 수정할 시 출력결과
내 생각을 테이블식으로 표현한 구조...
이런 느낌이지 않을까 ..
출처 : 블로그
참고
- 싱글톤으로 적합한 객체
- 상태가 없는 공유 객체: 상태를 가지고 있지 않은 객체는 동기화 비용이 없다. 따라서 매번 이 객체를 참조하는 곳에서 새로운 객체를 생성할 이유가 없다.
- 읽기용으로만 상태를 가진 공유 객체: 1번과 유사하게 상태를 가지고 있으나 읽기 전용이므로 여전히 동기화 비용이 들지 않는다. 매 요청마다 새로운 객체 생성할 필요가 없다.
- 공유가 필요한 상태를 지닌 공유 객체: 객체 간의 반드시 공유해야 할 상태를 지닌 객체가 하나 있다면, 이 경우에는 해당 상태의 쓰기를 가능한 동기화 할 경우 싱글톤도 적합하다.
- 쓰기가 가능한 상태를 지니면서도 사용빈도가 매우 높은 객체: 애플리케이션 안에서 정말로 사용빈도가 높다면, 쓰기 접근에 대한 동기화 비용을 감안하고서라도 싱글톤을 고려할만하다. 이 방법은 1. 장시간에 걸쳐 매우 많은 객체가 생성될 때, 2. 해당 객체가 매우 작은 양의 쓰기상태를 가지고 있을 때, 3. 객체 생성비용이 매우 클 때에 유용한 선택이 될 수 있다.
- 비싱글톤으로 적합한 객체
- 쓰기가 가능한 상태를 지닌 객체: 쓰기가 가능한 상태가 많아서 동기화 비용이 객체 생성 비용보다 크다면 싱글톤으로 적합하지 않다.
- 상태가 노출되지 않은 객체: 일부 제한적인 경우, 내부 상태를 외부에 노출하지 않는 빈을 참조하여 다른 의존객체와는 독립적으로 작업을 수행하는 의존 객체가 있다면 싱글톤보다 비싱글톤 객체를 사용하는 것이 더 나을 수 있다.
Wep에서 사용하는 scope 종류 (requst, session, globalsession...)
여기는 아직 실습을 진행하지 않았습니다. 실습을 하게되면 실습내용을 기준으로 다시 올리겠습니다.
request, session, global session, application, websocket의 Scope는 일반 Spring 어플리케이션이 아닌, Spring MVC Web Application에서만 사용되는 용도입니다. 이러한 범위를 벗어나 ClassPathXmlApplicationContext와 같은 일반적인 Spring IoC 컨테이너와 함께 사용하면 알 수 없는 Bean Scope에 대해 IllegalStateException이 발생합니다
- request scope
<bean id="loginAction" class="com.foo.LoginAction" scope="request"/>
- 위 정의에 따라, Spring container는 모든 HTTP request에 대해서 'loginAction' bean 정의에 대한 LoginAction 객체를 생성할 것이다. 즉, 'loginAction' bean은 HTTP request 수준에 한정된다(scoped). 요청에 대한 처리가 완료되었을 때, 한정된(scoped) bean도 폐기된다.
- session scope
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
- 위 정의에 따라, Spring container는 하나의 HTTP Session 일생동안 'userPreferences' bean 정의에 대한 UserPreferences 객체를 생성할 것이다. 즉, 'userPreferences' bean은 HTTP Session 수준에 한정된다(scoped). HTTP Session이 폐기될 때, 한정된(scoped) bean로 폐기된다.
- globalsession scope
<bean id="userPreferences" class="com.foo.UserPreferences" scope="globalSession"/>
- global session scope은 HTTP Session scope과 비슷하지만 단지 portlet-based web 어플리케이션에서만 사용할 수 있다.
- Portlet 명세(specifications)는 global Session을 하나의 portlet web 어플리케이션을 구성하는 여러 portlet들 모두가 공유하는 것으로 정의하고 있다.
- global session scope으로 설정된 bean은 global portlet Session의 일생에 한정된다.
'자바과정 > 스프링' 카테고리의 다른 글
스프링 실습 예제(static과 load로 외부 데이터 2개) (0) | 2021.04.07 |
---|---|
스프링 실습 예제 (외부 데이터 사용) (0) | 2021.04.07 |
스프링 라이프사이클 실습(생명주기, Bean 객체 생성 - 소멸) (0) | 2021.04.06 |
라이프 사이클이란? (0) | 2021.04.06 |
스프링 실습 예제 (어노테이션, Configuration/Bean) (0) | 2021.04.06 |
댓글