[Finally Spring] 1. 의존성 주입(DI, Dependency Injection): 스프링 컨테이너, 빈

---

요약

 

1) 의존성 주입(Dependency Injection)이란?

스프링 컨테이너(Spring Container)로부터 객체의 주소값을 전달받아 객체 간의 참조관계를 형성함으로써 '느슨한 결합(Loose Coupling)' 관계를 구축하는 것

2) 스프링 컨테이너(Spring Container)란?

●   스프링 프레임워크가 객체(빈, Bean)를 관리하기 위해 사용하는 컴포넌트

●   컨테이너(Container)란 내부에 또 다른 컴포넌트(Component)를 가지고 있는 어떤 컴포넌트를 의미.

●   컨테이너(Conatainer)는 객체를 생성하고 서로 연결해주며, 객체를 설정하고 생명주기를 관리.

●   객체의 의존성을 확인해 생성한 뒤 적절한 객체에 의존성을 주입 

●   실제 코드에서 스프링 컨테이너는 ApplicationContext라고하는 인터페이스로 구현됨

3) 스프링 컨테이너(Spring Container)의 역할과 장점

1. 서로 다른 빈을 연결해 애플리케이션의 빈을 연결하는 역할

2. 모듈 간의 의존 및 결합 문제 해결

3. 메서드가 언제 어디서 호출되어야 하는지나, 호출하기 위해 필요한 매개변수를 준비해서 전달하지 않음

4. 새로운 정책이 생기거나 수정 해야할 코드 발생 시 인터페이스만 수정하도록 수정 요소 최소화 가능

4) 스프링 컨테이너의 구성: Annotation, @

●   스프링 컨테이너는 XML 기반 구성 방식과 애너테이션(Annotation) 기반 구성 방식으로 나뉨

●   최근에는 자바코드를 이용한 애너테이션(Annotation, @) 방식으로 단일화되어가는 추세

5) 스프링 컨테이너의 종류

BeanFactory

1. 스프링 컨테이너의 최상위 인터페이스

2. 빈을 등록하고 생성하고 조회하고 돌려주는 등, 빈을 관리하는 역할 담당

3. getBean() 메소드를 통해 빈 인스턴스화(잘 사용하지 않음)

4. @Bean이 붙은 메서드 명을 스프링 빈의 이름으로 사용해 빈 등록

ApplicationContext

1. BeanFactory의 기능을 상속받아 제공

2. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공하고, 부가 기능 제공

3. 부가기능: MessageSource(메시지 다국어화), EnvironmentCapable(어플리케이션 구동 필요 정보 관리 인터페이스), ApplicationEventPublisher(이벤트 관리 인터페이스), ResourceLoader(파일, 클래스 path, 외부 등 리소스 조회)

6) 스프링 컨테이너를 이용한 의존성 주입(DI) 방법

생성자 주입(가장 추천). 생성자 주입이란 클래스의 필드멤버로 의존성을 주입할 다른 객체를 선언하고 이 객체를 생성자의 파라미터로 주입해주는 방식

public class ServiceTestImplement implements ServiceTest {
	private final TestInfo testInfo;
    
    public ServiceTestImplement(TestInfo testinfo) {
    this.testInfo = testinfo;
    }
}

7) 빈(Bean)이란?

●  빈(Bean)이란 스프링 컨테이너에 의해 관리되는 재사용 소프트웨어이자 컴포넌트(구성요소) 즉, 스프링 컨테이너에 등록되어 관리되는 '자바 객체'

●  일반 자바 객체와 달리 빈은 클래스의 등록 정보, getter/setter 메서드를 모두 포함하며 컨테이너에 사용되는 Configuration Metadata로 생성

●  해당 Metadata는 XML, JAVA Annotation, JAVA Code로 표현하며, 컨테이너의 명령과 인스턴스화, 설정, 조립할 객체를 정의

8) BeanDefinition이란?

스프링은 다양한 설정 형식을 BeanDefinition(빈 설정 메타정보)이라는 추상화 덕분에 지원

Bean은 BeanDefinition으로 정의되고 그에 따라서 활용하는 방법이 다름

BeanDefinition 기능 및 특징

1. 속성에 따라 컨테이너가 Bean을 어떻게 생성하고 관리할지 결정

2. @Bean(애너테이션) 또는 <bean>(XML) 하나 당 1개씩 메타정보가 생성

3. 설정 메타정보를 BeanDefinition 인터페이스를 통해 관리하기 때문에 컨테이너 설정을 XML, JAVA로 할 수 있다. 스프링 컨테이너는 설정 형식이 XML인지 JAVA코드인지 알 필요 없이 BeanDefinition만 알면 된다.

9) Bean Scope란?

빈 스코프(Bean Scope)란, 빈(Bean)이 존재할 수 있는 범위를 의미

앱이 구동되는 동안 한 개만 만들 것인지, 요청마다 생성할 것인지 등을 결정하는 것이 빈 스코프 

빈스코프(Bean Scope) 특징

1. 특정 Bean 정의에서 생성된 객체에 연결할 다양한 의존성, 구성값과 제어

2. 특정 bean 정의에서 생성된 객체의 범위를 제어

3. bean이 여러 범위 중 하나에 배치되도록 정의 가능

4. 구성을 통해 생성하는 객체의 범위를 선택 가능

5. 사용자 정의 범위 생성 가능

6. 스프링 프레임워크는 6개의 범위를 지원하며, 4개는 ApplicationContext를 사용하는 경우에만 사용 가능

빈스코프 종류(Bean Scope)

Scope	Description
Singleton	(Default) 각 Spring 컨테이너에 대한 단일 객체 인스턴스에 대한 단일 BeanDefinition의 범위를 지정 : 스프링 컨테이너 당 하나의 인스턴스만 사용한다
Prototype	스프링 컨테이너가 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 종료하는 스코프 : 매번 새로운 빈을 정의해서 사용
Request	웹 요청이 들어오고 나갈때까지 유지되는 스코프 : HTTP 라이프사이클마다 한 개의 빈 사용. web-aware context에만 사용가능 ex) Application Context
Session	웹 세션이 생성되고 종료될 때까지 유지되는 스코프 : HTTP 세션마다 하나의 빈 사용.  web-aware context에만 사용가능 ex) Application Context
Application	웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 : ServeletContext 라이프사이클 동안 한 개의 빈만 사용, web-aware context에만 사용가능
WebSocket	단일 BeanDefinition 범위를 WebSocket의 라이프사이클까지 확장. Spring ApplicationContext의 컨텍스트에서만 유효한 스코프 : WebSocket 라이프사이클 안에서 한 개의 빈만 사용. web-aware 컨텍스트만 사용 가능

 

10) 싱글톤 스코프(Singleton Scope)란?

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴. 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것을 의미. 즉, 싱글톤 패턴은 하나의 빈(Bean)을 여러번 사용할 수 있도록 캐시에 저장해놓고 쓰는 패턴

• 단일 Instance는 Singleton Bean의 캐시에 저장
• 이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 객체를 반환 (싱글톤 스코프의 스프링 빈은 여러번 호출해도 모두 같은 인스턴스 참조 주소값 가짐)
• 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너 종료될 때까지 유지
• 스프링 컨테이너는 싱글톤 빈(Singleton Bean)의 하나의 공유 인스턴스만 관리 필요(private 생성자를 사용해 외부에서 임의로 new를 사용하지 못하도록 해야함)
• 해당 BeanDefinition과 일치하는 ID, 또는 ID를 가진 빈(Bean)에 대한 모든 요청은 스프링 컨테이너에서 해당 특정 빈 인스턴스를 반환
• 스프링 컨테이너 종료 시 소멸 메서드도 자동으로 실행

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴입니다. 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것을 의미

싱글톤 패턴 단점

1. 새로운 객체를 만들지 못하도록 생성자를 private으로 지정: 자식 클래스 만들기 어려움, 유연성 부족

2. 1개의 인스턴스에서 속성값을 공유: 멀티쓰레드 환경에서 싱글톤 객체의 속성은 여러 쓰레드에 의해 바뀔 수 있어, 예상하지 못한 값 도출 가능 

3. 테스트가 어렵고 클라이언트가 구체적인 클래스에 의존하게 됨

4. 싱글톤 빈은 Application 구동 시 생성되어 초기 구동시 느림

 

 

11) 싱글톤 컨테이너(Singleton Container) 로서의 스프링 컨테이너(Spring Container)

스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리해주는 기능. 싱글톤 객체로 생성하고 관리하는 기능을 '싱글톤 레지스트리(Singleton Registry)'라고 함

싱글톤 패턴은 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 무상태(stateless)로 설계 필요

싱글톤 패턴의 주의점

1. 특정 클라이언트가 값 변경할 수 없어야 함

2. 오직 읽기만 가능해야 함

3. 스프링 빈의 공유값을 설정하면 장애가 발생할 수 밖에 없음

---

Prerequisite(필요 지식): Spring 기초 지식

2022.06.21 - [SPRING FRAMEWORK] - 자바 스프링 프레임워크(Spring Framework)란 무엇인가? POJO, DI, AOP, PSA

자바 스프링 프레임워크(Spring Framework)란 무엇인가? POJO, DI, AOP, PSA

 

 

이번 주제는 스프링에서 가장 중요한 개념인 DI(Dependency Injection), 의존성 주입입니다. 우리가 스프링을 쓰는 가장 큰 이유가 DI라 해도 과언이 아닙니다. DI를 정리해보면서 DI의 중요 개념인 스프링 컨테이너(Spring Container)와 스프링 빈(Spring Bean)에 대해 알아보겠습니다.

 

01. 의존성 주입(DI, Dependency Injection)이란?

 

의존성 주입(Dependency Injection)이란 스프링 프레임워크의 특징인 제어권 역전(IoC, Inversion of Control)를 구체화한 방법론입니다. '객체 간의 참조관계'를 의미하는 '의존성(Dependency)'과 '외부로부터 객체의 주소값을 전달'한다는 의미를 지닌 '주입(Injection)'의 의미를 합쳐 '외부로부터 객체의 주소값을 전달받아, 객체 간의 참조관계를 형성'하는 것을 말합니다. 

 

여기서 외부는 스프링 프레임워크가 제공하는 스프링 컨테이너(Spring Conatainer)입니다. 결국 정리하자면 의존성 주입이란, '스프링 컨테이너(Spring Container)로부터 객체의 주소값을 전달받아 객체 간의 참조관계를 형성함으로써 느슨한 결합 관계 구축하는 것'입니다.

 

객체를 참조하기 위해 객체 안에 다른 객체를 생성(new 키워드 사용)한다면 '강하게 결합(Tight Coupling)'되었다고 하고, 의존성 주입을 한다면 '느슨하게 결합(Loose Coupling)'되었다고 합니다.

 

객체들 간의 느슨한 결합은 요구사항의 변경에 유연한 대처를 가능하게 해주며, 의존성 주입은 강한 결합을 느슨하게 해줍니다. 스프링에서는 의존성 주입을 스프링 컨테이너를 이용해 직접 해주기 때문에 매우 편리합니다.

 

02. 스프링 컨테이너(Spring Container)이란?

 

스프링 프레임워크(Spring Framework)의 핵심 컴포넌트인 '스프링 컨테이너(Spring Container)'는 애플리케이션 내부에 존재하는 '빈(Bean)'의 생명주기를 관리합니다.

* 빈(Bean)? 스프링에서 관리하는 객체

 

★컨테이너(Container)란?

여기서 컨테이너(Container)란 내부에 또다른 컴포넌트(구성요소, Component)를 가지고 있는 어떤 컴포넌트를 의미합니다.

컨테이너(Container)는 객체를 생성하고 서로 연결해주며, 객체를 설정하고 생명주기를 관리해줍니다. 뿐만 아니라, 객체의 의존성을 확인해 생성한 뒤 적절한 객체에 의존성을 주입합니다. 

 

스프링 프레임워크는 스프링 컨테이너를 이용해 객체를 관리하며, 이 객체를 빈(Bean)이라고 합니다. 실제 코드에서 스프링 컨테이너는 Application Context라고하는 인터페이스(다형성 구현!)로 구현되어 있습니다. 

 

Application Context 인터페이스는 빈의 인스턴스화, 구성, 전체 생명 주기 및 삭제까지 관리합니다. 컨테이너는 개발자가 정의한 빈을 객체로 만들어 관리하고 개발자가 필요로 할 때 제공합니다. 의존성 주입을 구현하는 핵심이 바로 Application Context입니다.

 

02-1. 스프링 컨테이너의 역할과 장점

1. 서로 다른 빈을 연결해 애플리케이션의 빈을 연결하는 역할

2. 모듈 간의 의존 및 결합 문제 해결

3. 메서드가 언제 어디서 호출되어야 하는지나, 호출하기 위해 필요한 매개변수를 준비해서 전달하지 않음

4. 새로운 정책이 생기거나 수정 해야할 코드 발생 시 인터페이스만 수정하도록 수정 요소 최소화 가능

 

02-2. 스프링 컨테이너 생성 과정?

스프링 컨테이너는 XML 기반 구성 방식과 애너테이션(Annotation) 기반 구성 방식으로 나뉘어집니다. 그리고 최근에는 애너테이션 방식으로 단일화되어가는 추세이죠.

 

02-3.애너테이션(Annotation) 기반 컨테이너 구성

스프링 컨테이너는 Configuration Metadata를 사용해 컨테이너를 구축합니다. 그리고 스프링 컨테이너는 매개변수(parameter)로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록합니다.

 

코드로 보자면 new AnnotationConfigApplicationContext(구성정보.class)로 스프링에 있는 @Bean의 메서드를 등록합니다.

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

 

위와 같이 AppConfig.class 등의 구성 정보를 지정해줘서 ApplicationContext의 구현체인 스프링 컨테이너를 생성해야 합니다. 이를 컨테이너 인스턴스화라고 합니다. 스프링 컨테이너는 AppConfig에 있는 구성 정보를 통해서 필요한 객체들을 생성하게 됩니다.

 

클래스(POJO Class, 비즈니스로직)는 구성 메타데이터와 결합되어 ApplicationContext에 의해 생성 및 초기화된 후 완전히 구성되고 실행 가능한 시스템 또는 애플리케이션을 갖게 됩니다.

 

또한 스프링 빈 조회에서 상속관계가 있을 시 부모타입으로 조회하면 자식 타입도 함께 조회합니다. 따라서 모든 자바 객체의 부모타입인 object타입으로 조회하면 모든 스프링 빈을 조회합니다.

 

02-4. 스프링 컨테이너의 종류

BeanFactory

1. 스프링 컨테이너의 최상위 인터페이스

2. 빈을 등록하고 생성하고 조회하고 돌려주는 등, 빈을 관리하는 역할 담당

3. getBean() 메소드를 통해 빈 인스턴스화(잘 사용하지 않음)

4. @Bean이 붙은 메서드 명을 스프링 빈의 이름으로 사용해 빈 등록

 

ApplicationContext

1. BeanFactory의 기능을 상속받아 제공

2. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공하고, 부가 기능 제공

3. 부가기능: MessageSource(메시지 다국어화), EnvironmentCapable(어플리케이션 구동 필요 정보 관리 인터페이스), ApplicationEventPublisher(이벤트 관리 인터페이스), ResourceLoader(파일, 클래스 path, 외부 등 리소스 조회)

 

03. 스프링 컨테이너를 이용한 의존성 주입(DI) 방법

03-1. 생성자 이용 의존성 주입 

스프링에서 가장 추천하는 의존성 주입 방법은 '생성자를 이용한 의존성 주입'입니다. 생성자 주입이란 클래스의 필드멤버로 의존성을 주입할 다른 객체를 선언하고 이 객체를 생성자의 파라미터로 주입해주는 방식입니다. 코드 예시입니다.

 

public class ServiceTestImplement implements ServiceTest {
	private final TestInfo testInfo; // 필드 멤버로 삽입
    
    public ServiceTestImplement(TestInfo testinfo) { // 생성자 파라미터로 의존성 주입
    this.testInfo = testinfo;
    }
}

 

위 코드를 해석해보면 "ServiceTestImplement 클래스가 TestInfo라는 객체의 주솟값을 생성자의 파라미터를 이용해 주입받은 상태"입니다. 여기서 TestInfo는 Bean 설정에 따라 유연하게 변할 수 있습니다. ServiceTestImplement는 생성자를 통해 어떤 객체가 주입되는지 알 수 없고 알 필요도 없습니다. 이는 AppConfig가 알아서 결정하는 것이죠. 

 

04. 빈(Bean)이란?

빈(Bean)이란 스프링 컨테이너에 의해 관리되는 재사용 소프트웨어이자 컴포넌트(구성요소)입니다. 즉, 스프링 컨테이너에 등록되어 관리되는 '자바 객체'를 의미합니다. 스프링은 코드 상에 @Bean 애너테이션이 적힌 메서드를 모두 호출해 반환된 객체를 스프링 컨테이너에 등록합니다. 일반 자바 객체와 달리 빈은 클래스의 등록 정보, getter/setter 메서드를 모두 포함하며 컨테이너에 사용되는 Configuration Metadata로 생성됩니다.  해당 Metadata는 XML, JAVA Annotation, JAVA Code로 표현하며, 컨테이너의 명령과 인스턴스화, 설정, 조립할 객체를 정의합니다. 

 

04-1. BeanDefinition  

BeanDefinition 기능 및 특징

1. 속성에 따라 컨테이너가 Bean을 어떻게 생성하고 관리할지 결정

2. @Bean(애너테이션) 또는 <bean>(XML) 하나 당 1개씩 메타정보가 생성

3. 설정 메타정보를 BeanDefinition 인터페이스를 통해 관리하기 때문에 컨테이너 설정을 XML, JAVA로 할 수 있다. 스프링 컨테이너는 설정 형식이 XML인지 JAVA코드인지 알 필요 없이 BeanDefinition만 알면 된다.

 

빈의 정의를 읽기 위해서는 ApplicationContext를 사용해야 합니다.

// 빈 생성 및 환경 설정 -> ApplicationContext타입의 context
ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

// 설정된 빈 인스턴스 검색 -> context의 getBean() 메서드 이용한 검색 결과 값 저장한 service 객체 생성
StoreService service = context.getBean("market", marketService.class);

// 빈 인스턴스 사용 예 -> service 객체에서 유저이름리스트를 받아온 결과 값을 저장한 userList 생성
List<String> userList = service.getUsernameList();

 

 

위 코드를 보면 getBean() 메서드를 사용해 bean의 인스턴스를 가져올 수 있습니다. ApplicationContext 인터페이스는 bean을 가져오는 방법이 여러 개가 있지만, 실제로 코드 상에서는 getBean() 메서드로 호출을 사용하지 말아야합니다. 우리는 빈(Bean)의 정의를 알 필요가 없습니다. 이는 프레임워크의 몫이죠.

스프링은 다양한 설정 형식을 BeanDefinition(빈 설정 메타정보)이라는 추상화 덕분에 지원할 수 있습니다. Bean은 BeanDefinition으로 정의되고 그에 따라서 활용하는 방법이 달라집니다. 

 

04-2. 빈 스코프(Bean Scope)  

빈 스코프(Bean Scope)란, 빈(Bean)이 존재할 수 있는 범위를 의미합니다. 앱이 구동되는 동안 한 개만 만들 것인지, 요청마다 생성할 것인지 등을 결정하는 것이 바로 빈 스코프입니다. 

 

빈스코프(Bean Scope) 특징

1. 특정 Bean 정의에서 생성된 객체에 연결할 다양한 의존성, 구성값과 제어

2. 특정 bean 정의에서 생성된 객체의 범위를 제어

3. bean이 여러 범위 중 하나에 배치되도록 정의 가능

4. 구성을 통해 생성하는 객체의 범위를 선택 가능

5. 사용자 정의 범위 생성 가능

6. 스프링 프레임워크는 6개의 범위를 지원하며, 4개는 ApplicationContext를 사용하는 경우에만 사용 가능

 

빈스코프 종류(Bean Scope)

Scope	Description
Singleton	(Default) 각 Spring 컨테이너에 대한 단일 객체 인스턴스에 대한 단일 BeanDefinition의 범위를 지정 : 스프링 컨테이너 당 하나의 인스턴스만 사용한다
Prototype	스프링 컨테이너가 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 종료하는 스코프 : 매번 새로운 빈을 정의해서 사용
Request	웹 요청이 들어오고 나갈때까지 유지되는 스코프 : HTTP 라이프사이클마다 한 개의 빈 사용. web-aware context에만 사용가능 ex) Application Context
Session	웹 세션이 생성되고 종료될 때까지 유지되는 스코프 : HTTP 세션마다 하나의 빈 사용.  web-aware context에만 사용가능 ex) Application Context
Application	웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 : ServeletContext 라이프사이클 동안 한 개의 빈만 사용, web-aware context에만 사용가능
WebSocket	단일 BeanDefinition 범위를 WebSocket의 라이프사이클까지 확장. Spring ApplicationContext의 컨텍스트에서만 유효한 스코프 : WebSocket 라이프사이클 안에서 한 개의 빈만 사용. web-aware 컨텍스트만 사용 가능

 

스프링 컨테이너만 사용하여 객체를 생성하면 같은 클래스를 사용하더라도 각각 다른 주솟값의 메모리에 저장됩니다. 이는 메모리 낭비가 매우 심한 방법이죠. 스프링은 이 문제에 대한 해결 방법으로 싱글톤 패턴(Singleton Pattern)을 사용합니다.

 

04-3. 싱글톤 스코프(Singleton Scope)란?

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴입니다. 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것을 의미합니다. 

• 단일 Instance는 Singleton Bean의 캐시에 저장
• 이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 객체를 반환 (싱글톤 스코프의 스프링 빈은 여러번 호출해도 모두 같은 인스턴스 참조 주소값 가짐)
• 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너 종료될 때까지 유지
• 스프링 컨테이너는 싱글톤 빈(Singleton Bean)의 하나의 공유 인스턴스만 관리 필요(private 생성자를 사용해 외부에서 임의로 new를 사용하지 못하도록 해야함)
• 해당 BeanDefinition과 일치하는 ID, 또는 ID를 가진 빈(Bean)에 대한 모든 요청은 스프링 컨테이너에서 해당 특정 빈 인스턴스를 반환
• 스프링 컨테이너 종료 시 소멸 메서드도 자동으로 실행

 

싱글톤 패턴은 하나의 빈(Bean)을 여러번 사용할 수 있도록 캐시에 저장해놓고 쓰는 패턴으로 정리할 수 있습니다. 이 싱글톤 패턴 또한 여러 단점들이 존재합니다.

 

싱글톤 패턴 단점?

1. 새로운 객체를 만들지 못하도록 생성자를 private으로 지정: 자식 클래스 만들기 어려움, 유연성 부족

2. 1개의 인스턴스에서 속성값을 공유: 멀티쓰레드 환경에서 싱글톤 객체의 속성은 여러 쓰레드에 의해 바뀔 수 있어, 예상하지 못한 값 도출 가능 

3. 테스트가 어렵고 클라이언트가 구체적인 클래스에 의존하게 됨

4. 싱글톤 빈은 Application 구동 시 생성되어 초기 구동시 느림

 

위에 존재하는 싱글톤 패턴의 문제를 해결하기 위해 스프링은 싱글톤 컨테이너(Singleton Container) 기능을 지원합니다.

 

04-4. 스프링 컨테이너의 기능: 싱글톤 컨테이너(Singleton Container)  

스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리해주는 기능이 있습니다. 싱글톤 객체로 생성하고 관리하는 기능을 '싱글톤 레지스트리(Singleton Registry)'라고 합니다.

 

객체의 생성을 최소화하는 이점이 있는 싱글톤 패턴에도 주의점이 있습니다.

싱글톤 패턴은 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 무상태(stateless)로 설계해야 합니다.

싱글톤 패턴의 주의점

1. 특정 클라이언트가 값 변경할 수 없어야 함

2. 오직 읽기만 가능해야 함

3. 스프링 빈의 공유값을 설정하면 장애가 발생할 수 밖에 없음