Spring Context

Spring Context

 

스프링이 관리하는 Bean들이 담겨있는 컨테이너

• 스프링의 가장 큰 특징 중 하나가 IoC 컨테이너를 통해 객체의 생성을 관리하는 것으로 Context가 Container의 일종임

Container란?

• Container에는 Bean Factory와 이를 상속한 Application Context 2가지 유형이 있음

Bean Factory

• Pre-Loading 방식
• Bean 객체를 생성하고 관리하는 기본적인 기능

Application Context

• Lazy Loading 방식
• 트랜잭션 관리, 메시지 기반의 다국어 처리, AOP 처리 등

Spring Container 사용 이유

• 모든 Context는 싱글톤으로 관리되어 유일한 객체로 관리됨
• Lazy Loading으로 Servlet Context를 관리하기 때문에 메모리 관리 용이
• DAO(Data Access Object), VO(Value Object)를 사용하여 POJO를 간편하게 구현 할 수 있게 도와 줌

Context의 종류는 ApplicationContext, WebApplicationContext, ServletContext가 있음

 

Application Context

스프링의 핵심 컨테이너로서, 스프링 애플리케이션 전체에 걸쳐 스프링 빈의 생성, 관리, 라이프사이클을 담당

 

ApplicationContext 인터페이스를 구현하는 다양한 컨텍스트 구현체들이 있으며 주로 사용되는 것으로는 AnnotationConfigApplicationContext, ClassPathXmlApplicationContext, FileSystemXmlApplicationContext 등이 있음

 

빈(Bean) 요청 시 처리 과정

클라이언트에서 해당 빈을 요청하면 애플리케이션 컨텍스트는 다음과 같은 과정을 거쳐 빈을 반환한다.

1. ApplicationContext는 @Configuration이 붙은 클래스들을 설정 정보로 등록해두고, @Bean이 붙은 메서드의 이름으로 빈 목록을 생성한다
2. 클라이언트가 해당 빈을 요청한다
3. ApplicationContext는 자신의 빈 목록에서 요청한 이름이 있는지 찾는다
4. ApplicationContext는 설정 클래스 빈 생성을 요청하고, 생성된 빈을 돌려준다

애플리케이션 컨텍스트는 @Configuration이 붙은 클래스들을 설정 정보로 등록해두고, @Bean이 붙은 메서드의 이름으로 빈 목록을 생성한다

클라이언트가 해당 빈을 요청하면 애플리케이션 컨텍스트는 자신의 빈 목록에서 요청한 이름이 있는지 찾고, 있으면 해당 빈 생성 메서드(@Bean)을 호출하여 객체를 생성하고 돌려준다

• Spring 내부에서 Reflection API를 이용해 빈 정의에 나오는 클래스 이름을 이용하거나 빈 팩토리를 통해 빈을 생성한다

Application Context의 장점

• 클라이언트는 @Configuration이 붙은 구체적인 팩토리 클래스를 알 필요가 없다
• 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다
• 애플리케이션 컨텍스트를 통해 다양한 빈 검색 방법을 제공할 수 있다

클라이언트는 @Configuration이 붙은 구체적인 팩토리 클래스를 알 필요가 없다

애플리케이션이 발전하면 팩토리 클래스가 계속해서 증가하는데, 애플리케이션 컨텍스트가 없다면 클라이언트는 원하는 객체를 가져오기 위해 어떤 팩토리 클래스에 접근해야 하는지 알아야 하는 번거로움이 생긴다.

애플리케이션 컨텍스트를 사용하면 팩토리가 아무리 많아져도 이에 직접 접근할 필요가 없어진다(일관된 방식으로 원하는 빈을 가져올 수 있음)

 

애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다

애플리케이션 컨텍스트는 객체의 생성과 관계 설정이 다가 아님, 객체가 만들어지는 방식과 시점 및 전략 등을 다르게 가져갈 수 있고, 그 외에도 후처리나 정보의 조합 인터셉트 등과 같은 다양한 기능이 존재한다.

 

애플리케이션 컨텍스트를 통해 다양한 빈 검색 방법을 제공할 수 있다

애플리케이션 컨텍스트에서 빈 목록을 관리하여, 빈의 이름이나 타입 또는 어노테이션 설정 등으로 빈을 찾을 수 있으며, 이러한 빈을 직접 찾는 방식은 의존성 검색(dependency lookup)으로 불림

 

Web Application Context

웹 애플리케이션에서 사용되는 스프링 컨텍스트로, ApplicationContext 인터페이스를 확장한 WebApplicationContext 인터페이스를 구현한다.

웹 애플리케이션의 라이프사이클과 웹 관련 기능을 제공

 

주로 사용되는 것으로는 XmlWebApplicationContext, AnnotationConfigWebApplication 등이 있다

 

Servlet Context

서블릿 기반 웹 애플리케이션에서 사용되는 컨텍스트로 웹 애플리케이션의 설정, 리소스 액세스, 서블릿, 필터 등의 웹 구성 요소를 관리, 웹 애플리케이션마다 별도의 ServletContext 인스턴스가 생성되어 사용됨

WebApplicationContext는 ServletContext를 상속받는 인터페이스로, 웹 애플리케이션 컨텍스트를 구현하는 데 사용됨

 

Spring Context의 종류는 엄청 많지만 Web Application용 Context는 Root Context와 Servlet Context 두 가지로 나눌 수 있음

 

Root Context(공통 부분)

• 스프링 애플리케이션의 전역적인 설정과 빈(Bean)들을 포함하는 상위 컨텍스트
• 주로 데이터베이스 연결, 서비스 계층, 비즈니스 로직 등의 공통적인 설정을 담당
• Root Context는 보통 applicationContext.xml 파일로 작성되며, 프로젝트 전체에서 공유되는 빈(Bean)들을 정의
• ContextLoaderListenerd에 의해 생성된다.
• 여러 개의 서블릿 컨텍스트가 하나의 루트 컨텍스트를 참조할 수 있음

Servlet Context(개별 부분)

• 스프링 MVC와 관련된 설정과 빈(Bean)들을 포함하는 컨텍스트
• 주로 웹 애플리케이션의 요청 처리, 컨트롤러, 뷰(View) 등과 관련된 설정을 담당
• 각각의 서블릿(DispatcherServlet)마다 별도의 서블릿 컨텍스트가 생성됨
• 서블릿 컨텍스트는 보통 servlet-context.xml 파일로 작성되며, 해당 서블릿에 대한 설정과 빈(Bean)들을 정의
• DispatcherServlet에 의해 생성된다
• 서블릿 컨텍스트는 루트 컨텍스트를 참조할 수 있다

Servlet Context에서 빈을 먼저 찾고, Application Context에 정의된 Bean을 찾는다.

• Servlet Context에 정의된 Bean은 Application Context에서 정의된 Bean을 사용할 수 있다.

 

스프링(Spring)의 싱글톤(Singleton)

Spring에서 Singleton을 사용하는 이유

애플리케이션 컨텍스트에 의해 등록된 빈은 기본적으로 싱글톤으로 관리 됨(스프링에 여러 번 빈을 요청하더라도 매번 동일한 객체를 돌려줌)

 

애플리케이션 컨텍스트가 싱글톤으로 빈을 관리하는 이유는 대규모 트래픽을 처리할 수 있도록하기 위함이다.

 

스프링은 대규모의 엔터프라이즈 환경에서 요청을 처리할 수 있도록 고안되었고 그에 따라 계층적으로 처리 구조(Controller, Service, Repository 등)가 나뉘어지게 되었다.

 

그런데 매번 클라이언트 요청이 올 때마다 각 로직을 처리하는 빈을 새로 만들어서 사용해야 한다고 하면 GC의 성능이 좋아도 부하가 걸리면 문제가 발생할 수 밖에 없다.

 

이러한 문제를 해결하기 위해 빈을 싱글톤 스코로 관리하여 1개의 요청이 왔을 때 여러 쓰레드가 빈을 공유해 처리하도록 함

 

Spring에서 관리하는 싱글톤의 장점

싱글톤 레지스트리(Singleton Registry) : 스프링이 직접 제공하는 싱글톤 형태의 오브젝트를 만들고 관리하는 기능

• static 메서드나 private 생성자 등을 사용하지 않아 객체지향적 개발을 할 수 있다
• 테스트를 하기 편리하다

기본적으로 싱글톤이 멀티쓰레드 환경에서 서비스 형태로 사용되기 위해서는 내부에 상태 정보를 갖지 않는 무상태(Stateless) 방식으로 만들어져야 하며, 이를 직접 구현하면 여러 문제들이 발생할 수 있음