[Spring] 애플리케이션 컨텍스트(Application Context)와 스프링의 싱글톤(Singleton)

이번에는 애플리케이션 컨텍스트에 대해 간단히 알아보도록 하겠습니다.

 

 

 

1. 애플리케이션 컨텍스트(Application Context)

---

[ 애플리케이션 컨텍스트(Application Context)란? ]

Spring에서는 빈의 생성과 관계설정 같은 제어를 담당하는 IoC(Inversion of Control) 컨테이너인 빈 팩토리(Bean Factory)가 존재한다. 하지만 실제로는 빈의 생성과 관계설정 외에 추가적인 기능이 필요한데, 이러한 이유로 Spring에서는 빈 팩토리를 상속받아 확장한 애플리케이션 컨텍스트(Application Context)를 주로 사용한다.

애플리케이션 컨텍스트는 별도의 설정 정보를 참고하고 IoC를 적용하여 빈의 생성, 관계설정 등의 제어 작업을 총괄한다. 애플리케이션 컨텍스트에는 직접 오브젝트를 생성하고 관계를 맺어주는 코드가 없고, 그런 생성 정보와 연관관계 정보에 대한 설정을 읽어 처리한다. 예를 들어 @Configuration과 같은 어노테이션이 대표적인 IoC의 설정정보이다.

 

 

[ 빈(Bean) 요청 시 처리 과정 ]

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

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

 

애플리케이션 컨택스트는 @Configuration이 붙은 클래스들을 설정 정보로 등록해두고, @Bean이 붙은 메소드의 이름으로 빈 목록을 생성한다. 그리고 클라이언트가 해당 빈을 요청한다면 애플리케이션 컨텍스트는 자신의 빈 목록에서 요청한 이름이 있는지 찾고, 있다면 해당 빈 생성 메소드(@Bean)을 호출하여 객체를 생성하고 돌려준다. (구체적으로는 Spring 내부에서 Reflection API를 이용해 빈 정의에 나오는 클래스 이름을 이용하거나 또는 빈 팩토리를 통해 빈을 생성한다.)

 

 

 

 

[ 애플리케이션 컨텍스트(Application Context)의 장점 ]

이렇듯 애플리케이션 컨텍스트를 사용하면 다음과 같은 장점들을 얻을 수 있다.

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

 

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

애플리케이션이 발전하면 팩토리 클래스가 계속해서 증가할 것이다. 애플리케이션 컨텍스트가 없다면 클라이언트는 원하는 객체를 가져오려면 어떤 팩토리 클래스에 접근해야 하는지 알아야 하는 번거로움이 생긴다. 반면에 애플리케이션 컨텍스트를 사용하면 팩토리가 아무리 많아져도 이에 직접 접근할 필요가 없어진다. 즉, 일관된 방식으로 원하는 빈을 가져올 수 있다.

 

 

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

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

 

 

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

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

 

 

 

 

 

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

---

[ Spring에서 싱글톤을 사용하는 이유 ]

애플리케이션 컨텍스트에 의해 등록된 빈은 기본적으로 싱글톤으로 관리된다. 즉, 스프링에 여러 번 빈을 요청하더라도 매번 동일한 객체를 돌려준다는 것이다. 애플리케이션 컨텍스트가 싱글톤으로 빈을 관리하는 이유는 대규모 트래픽을 처리할 수 있도록 하기 위함이다.

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

그런데 매번 클라이언트에서 요청이 올 때마다 각 로직을 처리하는 빈을 새로 만들어서 사용한다고 생각해보자. 요청 1번에 5개의 객체가 만들어진다고 하고, 1초에 500번 요청이 온다고 하면 초당 2500개의 새로운 객체가 생성된다. 아무리 GC의 성능이 좋아졌다 하더라도 부하가 걸리면 감당이 힘들 것이다.

그래서 이러한 문제를 해결하고자 빈을 싱글톤 스코프로 관리하여 1개의 요청이 왔을 때 여러 쓰레드가 빈을 공유해 처리하도록 하였다.

 

 

 

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

Java로 기본적인 싱글톤 패턴을 구현하고자 하면 다음과 같은 단점들이 발생한다.

• private 생성자를 갖고 있어 상속이 불가능하다.
• 테스트하기 힘들다.
• 서버 환경에서는 싱글톤이 1개만 생성됨을 보장하지 못한다.
• 전역 상태를 만들 수 있기 때문에 객체지향적이지 못하다.

 

그래서 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공하는데, 그것이 바로 싱글톤 레지스트리(Singleton Registry) 이다. 스프링 컨테이너는 싱글톤을 생성하고, 관리하고 공급하는 컨테이너이기도 하다. 싱글톤 레지스트리의 장점은 다음과 같다.

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

기본적으로 싱글톤이 멀티쓰레드 환경에서 서비스 형태의 객체로 사용되기 위해서는 내부에 상태정보를 갖지 않는 무상태(Stateless) 방식으로 만들어져야 한다. 만약 여러 쓰레드들이 동시에 상태를 접근하여 수정한다면 상당히 위험하기 때문이다.

직접 싱글톤을 구현한다면 상당히 많은 단점들이 있겠지만, Spring 프레임워크에서 직접 싱글톤으로 객체를 관리해주므로, 우리는 더욱 객체지향적인 개발을 할 수 있게 된 것이다.

 

 

 

애플리케이션 컨텍스트와 관련된 보다 심화적인 내용을 알고 싶다면 여기를 참고해주세요!