Java Container

Mixer·2022년 6월 16일

스프링 컨테이너

스프링 컨테이너는 내부에 존재하는 애플리케이션 빈의 생명주기를 관리한다.

빈 생성, 관리, 제거 등의 역할을 담당한다

스프링 컨테이너는 뭘까?

ApplicationContext를 스프링 컨테이너라고 하고 인터페이스로 구현되어 있다.(다형성 적용)

스프링 컨테이너는 XML, 애너테이션 기반의 자바 설정 클래스로 만들수 있다.
이전엔 개발자가 XML을 통해 모두 설정해야했지만, 이런 복잡한 부분들을 Spring Boot를 사용하면서 더 이상 사용하지 않게되었다.
빈의 인스턴스화, 구성, 전체 생명 주기 및 제거까지 처리
(컨테이너는 개발자가 정의한 빈을 객체로 만들어 관리하고 개발자가 필요로 할 때 제공)
스프링 컨테이너를 통해 원하는 만큼 많은 객체를 가질 수 있다.
의존성 주입을 통해 애플리케이션의 컴포넌트를 관리한다
- 스프링 컨테이너는 서로 다른 빈을 연결해 어플리케이션의 빈을 연결하는 역할
- 개발자가 모듈 간에 의존 및 결합으로 인해 발생한 문제로부터 자유로울 수 있다.
- 메서드가 언제,어디서 호출되야하는지, 메서드를 호출하기 위해 필요한 매개 변수를 준비해서 전달하지 않는다.

왜 사용할까?

객체를 사용하기 위해 new 생성자를 써야 했다.
애플리케이션에서 이런 객체가 무수히 많이 존재하고 서로 참조하게 되어있었다.
- 서로 참조가 심할수록 의존성이 높다
- 낮은 결합도와 높은 캡슐화가 객체지향프로그래밍의 핵심 중 하나인데 높은 의존성은 이를 지킬수없다.
객체 간의 의존성을 낮추기위해 Spring 컨테이너가 사용된다.

그래서, 기존의 방식으론 새로운 정책이 생기게 될 경우 변경 사항들을 수작업으로 수정이 필요했다.
서로 의존이 많이 되어있지 않는 작업 초반부에는 하나 하나 수정이 가능하지만, 점점 서비스의 코드가 방대해질 경우 의존도는 높아져있을거고 그에 따른 코드의 변경도 많이 필요해질것이다
하지만, 스프링 컨테이너를 사용하면서 구현 클래스에 있는 의존을 제거하고 인터페이스에만 의존하도록 설계할 수 있다.

어떻게 생성하나?

스프링 컨테이너는 Configuration Metadata를 사용한다
스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해 스프링 빈에 등록한다
new AnnotationConfigApplicationContext(구성정보.class) 로 스프링에 있는 @Bean의 메서드를 등록한다
애너테이션 기반 컨테이너 구성
애너테이션 기반의 자바 설정 클래스로 Spring을 만드는 것을 뜻한다

// Spring Container 생성
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

XML 기반으로 만드는 ClassPathXmlApplicationContext도 있다

XML 기반 구성 메타데이터 기본 구조

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">
        
    <bean id="..." class="...">  
        <!-- collaborators and configuration for this bean go here -->
     </bean>
        
     <bean id="..." class="...">
         <!-- collaborators and configuration for this bean go here -->
     </bean>
        
     <!-- more bean definitions go here -->
        
</beans>

<beans /> 에 필요한 값을 설정한다
<bean id="...">: 빈 정의를 식별하는데 사용되는 문자열
<bean class="...">: 빈의 유형을 정의하고 클래스 이름을 사용한다

스프링 컨테이너를 만드는 다양한 방법은 ApplicationContext 인터페이스 구현체이다

AppConfig.class 등의 구성 정보를 지정해줘 스프링 컨테이너를 생성해야 한다
AppConfig에 있는 구성 정보를 통해 스프링 컨테이너는 필요한 객체들을 생성하게 된다
애플리케이션 클래스는 구성 메타데이터와 결합되어 AplicationContext 생성 및 초기화된 후 완전히 구성되고 실행 가능한 시스템 또는 애플리케이션을 갖게 된다.

스프링 빈 조회에서 상속관계가 있을 시 부모타임으로 조회하면 자식 타입도 함께 조회한다.
만약 모든 자바 객체의 최고 부모인 object타입으로 조회하면 모든 스프링 빈을 조회한다.

스프링 컨테이너의 종류

파라미터로 넘어온 설정 클래스 정보를 참고해서 빈의 생성, 관계 설정 등의 제어작업을 총괄하는 컨테이너이다.

BeanFactory

스프링 컨테이너의 최상위 인터페이스이다, 빈을 등록하고 생성하고 조회하고 돌려주는 등 빈을 관리하는 역할을 한다
getBean() 메소드를 통해 빈을 인스턴스화 할 수 있다.
@Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용해 'Bean 등록' 을 한다

ApplicationContext

BeanFactory의 기능을 상속받아 제공한다 빈을 관리하고 검색하는 기능을 BeanFactory가 제공하고 그 외에 부가 기능을 제공한다

부가기능
MessageSource : 메세지 다국화를 위한 인터페이스
EnvironmentCapable : 개발, 운영 등 환경변수 등으로 나눠 처리하고, 애플리케이션 구동 시 필요한 정들을 관리하기 위한 인터페이스
ApplicationEventPublisher : 이벤트 관련 기능을 제공하는 인터페이스
ResourceLoader : 파일, 클래스 패스, 외부 등 리소스를 편리하게 조회

컨테이너 인스턴스화

ApplicationContext 생성자에 제공된 위치 경로 또는 경로는 컨테이너가 로컬 파일 시스템, Java CLASSPATH 등과 같은 다양한 외부 리소스로부터 구성 메타데이터를 로드할 수 있도록 하는 리소스 문자열

// Annotation
ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

//XML
ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

new 생성자와 주입 코드의 차이점

new 를 통해 직접 객체 생성 방식

public class OrderServiceImpl implements OrderService {
	private final UserRepository userRepository = new UserRepositoryImpl();
    private final DiscountInfo discountInfo = new RateDiscountInfo();
    
    @Override
    public Order createOrder(Long userId, String itemName. int itemPrice) {
    	User user = userRepository.findByUserId(userId);
        int discountPrice = discountInfo.discount(user, itemPrice);
        return new Order(userId, itemName, itemPrice, discountPrice);
       }
     }

생성자 주입을 통해 IoC & DI

public class OrderServiceImpl implements OrderService {
	private final UserRepository userRepository;
    private final DiscountInfo discountInfo;
    
    public OrderServiceImpl(UserRepository userRepository, DiscountInfo discountInfo) {
    	this.userRepository = userRepository;
        this.discountInfo = discountInfo;
        }
    
    @override
    public Order createOrder(Long userId, String itemName, int itemPrice) {
    User user = userRepository.findByUserId(userId);
    int discountPrice = discountInfo.discount(user, itemPrice);
    return new Order(userId, itemName, itemPrice, discountPrice);
    }
 }

new를 사용하는 대신 생성자를 통해 의존 객체가 주입되고, 느슨한 의존 관계가 이루어진다
userRepository와 discountInfo의 구현 클래스는 Bean 설정에 따라 유연하게 변하게 된다
OrderServiceImpl 입장에선 생성자를 통해 어떤 구현 객체가 주입될지 알 수 없으며, 알 필요도 없다
어떤 객체가 주입될지는 외부(AppConfig)에서 결정한다
OrderServiceImpl 는 오로지 실행에만 집중하게 된다

BeanDefinition

스프링은 BeanDefinition을 통해 다양한 형식의 설정 파일을 지원한다.
어떠한 설정 파일을 사용하더라도 BeanDefinition 형식의 메타 정보를 생성해주고, 스프링 컨테이너는 설정 파일의 형식과 상관없이 BeanDefinition을 통해 빈의 정보를 알아낼 수 있다.
빈이 존재할 수 있는 범위를 의미한다

특정 빈 정의에서 생성된 개체에 연결할 다양한 의존성 및 구성 값 뿐 아니라 특정 빈 정의에서 생성된 개체의 범위도 제어할 수 있다.
Spring Framework 는 6개의 범위를 지원하며, 그 중 4개는 ApplicationContext를 사용하는 경우에만 사용할 수 있다.
빈은 여러 범위 중 하나에 배치되도록 정의할 수 있다.
구성을 통해 생성하는 개체의 범위를 선택할 수 있기 때문에 강력하고 유연하다ㅣ
사용자 정의 범위를 생성할 수도 있다.

Scope	Description
singleton	(default) 각 스프링 컨테이너에 대한 단일 객체 인스턴스에 대한 단일 bean definition의 범위를 지정한다.
prototype	스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.
request	웹 요청이 들어오고 나갈때까지 유지되는 스코프
session	웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
application	웹이 서블릿 컨텍스와 같은 범위로 유지되는 스코프
websocket	단일 bean definition 범위를 WebSocket의 라이프사이클까지 확장, Spring ApplicationContext의 컨테스트에서만 유효하다

beanClassName : 생성할 빈의 클래스 이름
constructorArgumentValue : 생성자 이름과 설정값
dependsOn : 생성 순서가 보장되어야 하는 경우를 위해 먼저 생성되어야 하는 빈 지정
description : 빈 생성 시 작성한 설명
destroyMethodName : 빈의 생명주기가 끝나서 소멸되기 전 호출되는 메서드 이름
factoryBeanName : 팩토리 역할읠 빈을 사용할 경우 이름
factoryMethodName : 빈을 생성할 팩토리 메서드의 이름
initMethodName : 빈을 생성하고 의존관계 적용 후 호출되는 초기화 메서드 이름
parentName : 빈 메타 정보를 상속받을 부모 BeanDefinition 이름
propertyvalues : 빈의 새 인스턴스에 적용할 속성 값
resourceDescription : BeanDefinition이 나온 리소스에 대한 설명
scope : 빈 오브젝트의 생명 주기 (default : 싱글톤)

싱글톤 스코프 (Singleton Scope) 란 ?
어플리케이션 전반에 걸쳐 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것

Singleton Scope

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

스프링 컨테이너의 시작과 함께 생성되어 스프링 컨테이너가 종료될때까지 유지된다.
싱글톤 빈의 하나의 공유 인스턴스만 관리하게 된다 : private 생성자를 사용해 외부에서 임의로 new를 사용하지 못하도록 막아야한다
해당 bean definition와 일치하는 ID 또는 ID를 가진 빈에 대한 모든 요청은 스프링 컨테이너에서 해당 특정 빈 인스턴스를 반환한다, 스프링 컨테이너가 종료 시 소멸 메서드도 자동으로 실행

정리하면

싱글턴은 해당 빈의 인스턴스를 오직 하나만 생성해 사용하는 것을 의미한다
단일 인스턴스는 싱글톤 빈의 캐시에 저장된다
이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 개체를 반환한다.
- 싱글톤 스코프의 스프링 빈은 여러번 호출해도 모두 같은 인스턴스 참조 주소값을 나타낸다
작동 방식

싱글톤 패턴의 문제점

싱글톤 패턴을 구현하는 코드 자체가 많다
의존관계상 클라이언트가 구체 클래스에 의존한다
지정해서 가져오기 때문에 테스트하기 어렵다.
private 생성자를 사용하여 자식 클래스를 만들기 어렵기 때문에 유연성이 떨어진다.
속성 공유
- 멀티쓰레드 환경에서 싱글톤 객체의 속성은 여러 쓰레드에 의해 바뀔 수 있다.
- A 쓰레드에선 속성 값을 x로 바꾸고 출력하는 과정에서 B 쓰레드가 속성 값을 y로 바꾸면 쓰레드 A에선 예상치 못한 값이 출력될수 있다.(1개의 인스턴스에서 속성 값을 공유하기 때문에 발생하는 문제점)
- 가급적 읽기만 가능해야 한다
Application 초기 구동 시 인스턴스 생성
- 싱글톤 빈은 기본적으로 애플리케이션 구동 시 생성되므로 싱글톤 빈이 많을 수록 구동 시간이 증가할 수 있다.

싱글톤 패턴 문제를 싱글톤 컨테이너가 해결해준다

스프링 컨테이너는 싱글톤 컨테이너 역할을 한다
싱글톤 객체로 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다
스프링 컨테이너의 위 기능 덕에 싱글턴 패턴의 모든 단점을 해결하며 객체를 싱글톤으로 유지할 수 있다.

싱글톤 방식의 주의점

싱글톤 방식은 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 무상태로 설계해야한다
- 특정 클라이언트가 값을 변경할 수 있으면 안된다
- 읽기만 가능해야한다
- 스프링 빈의 공유 값을 설정하면 장애가 발생할 수 밖에 없다.

Mixer

Minthug'life

이전 포스트

Java Spring Boot

다음 포스트