[스프링 핵심 3] 스프링 컨테이너와 빈 & 싱글톤 컨테이너

[섹션 3, 4 ]

2024.10.15 - [스프링] - [스프링 핵심 2] 스프링 핵심 원리 이해

[스프링 핵심 2] 스프링 핵심 원리 이해

---

[섹션 5] 스프링 컨테이너와 스프링 빈

• ApplicationContext =  스프링 컨테이너 = 인터페이스
• 스프링 컨테이너 만드는 방식
  • XML을 기반
  • 애노테이션 기반의 자바 설정 클래스 ( AppConfig 를 사용했던 방식 )

1. 스프링 컨테이너 생성

2. 스프링 빈 등록

주의
빈 이름은 항상 다른 이름을 부여해야 한다

 

3. 스프링 빈 의존관계 설정

 

참고
스프링은 빈을 생성하고, 의존관계를 주입하는 단계가 나누어져 있다.
그런데 이렇게 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다

 

 

 

1. 컨테이너에 등록된 모든 빈 조회

ROLE_APPLICATION : 일반적으로 사용자가 정의한 빈
ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

 

2. 스프링 빈 조회

 

• 테스트 1: 이름으로 조회 (인터페이스)
• 테스트 2 : 타입으로 조회 (인터페이스)
• 테스트 3 : 구체 타입 (객체)로 조회
  • 객체인 MemberServiceImpl을 사용해서 조회 => 유연성 떨어짐
• 테스트 4 : 실패 테스트
  • 없는 bean을 입력해서 조회 -> 오류 발생
  • asserThrow를 사용해서 오류 해결

 

3. 스프링 빈 조회 - 동일한 타입이 둘 이상

⇒ 타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류 발생 ⇒ 빈 이름을 지정

 

•  같은 타입의 컨테이너를 두개 만들고 테스트 할 것

 

---

• 테스트 1: 타입으로만 조회
  • 두개의 타입은 같으므로 오류 발생
  • assertThrows를 이용해서 오류 해결하도록 코드 수정
• 테스트 2 : 이름 지정하도록
  • name을 지정해서 빈을 조회
• 테스트 3 : 타입 둘다 조회
  • 키-벨류 형태로 조회해서 두개 다 있는지 조회함

 

 

 

4. 스프링 빈 조회 - 상속 관계

부모 타입으로 조회하면, 자식 타입도 함께 조회함
그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회 가능

 

•  DiscountPolicy의 자식인 rate와 fix 두개의 빈 사용

 

---

• 테스트 1 : 부모 타입(DiscountPolicy) 으로 조회
  • 자식이 두개 있으므로 오류 발생 -> assertThrows 로 오류 해결
• 테스트 2 : 빈 이름을 지정하도록 수정
• 테스트 3 : 구체 타입 (rateDiscountPolicy 라고) 지정
  • 해당 타입은 한개밖에 없으므로 성공했지만, 유연성 떨어지므로 안좋은 방법
• 테스트 4 : 부모 타입으로 모두 조회
• 테스트 5 : 부모 타입으로 모두 조회해서, 스프링 내부 빈들도 출력

 

5. BeanFactory와 ApplicationContext

 

 

 

• BeanFactory
  • 스프링 컨테이너의 최상위 인터페이스
  • 스프링 빈을 관리하고 조회하는 역할 담당
  • getBean() 을 제공
  • 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능
• ApplicationContext
  • BeanFactory의 기능을 상속받음
  • 빈 관리기능 + 편리한 부가 기능 제공
  • 애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능이 필요

ApplicatonContext가 제공하는 부가기능
- 메시지소스를 활용한 국제화 기능
- 환경변수
- 애플리케이션 이벤트
- 편리한 리소스 조회

 

6. XML 

xml 기반의 appConfig.xml 스프링 설정 정보와 자바 코드로 된 AppConfig.java 설정 정보를 비교해보면 거의 비슷하다는 것을 알 수 있다 → 최근에 잘 사용하지 않음

 

7. 스프링 빈 설정 메타 정보 - BeanDefinition

• 스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까? ➡️ BeanDefinition 이라는 추상화가 있다 !
• 쉽게 이야기해서 역할과 구현을 개념적으로 나눈 것이다!
  • XML을 읽어서 BeanDefinition을 만들면 된다. 자바 코드를 읽어서 BeanDefinition을 만들면 된다.
  • 스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다.
  • 오직 BeanDefinition만 알면 된다.
• BeanDefinition 을 빈 설정 메타정보라 한다.
  • @Bean , <bean> 당 각각 하나씩 메타 정보가 생성된다.
• 스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다

 ⇒ 스프링 컨테이너는 BeanDefinition 만 의존함

 

---

[섹션 6] 싱글톤 컨테이너

1. 웹 애플리케이션과 싱글톤

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.

[ 스프링 없는 순수한 DI 컨테이너 테스트 ]

• 요청을 할 때 마다 객체를 새로 생성 ➡️ 메모리 낭비가 심함
• 해결방안 ) 해당 객체가 딱 1개만 생성되고, 공유하도록 설계 ➡️ 싱글톤 패턴

 

2. 싱글톤 패턴

⇒ 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 함

✅ private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막음

객체를 static에 선언해서 한개만 만듦
생성자는 private으로 선언해서, 외부에서 사용하지 못하도록 함

 

✅ 싱글톤의 문제

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어감
• 의존관계상 클라이언트가 구체 클래스에 의존함 → DIP를 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높음
• 테스트하기 어려움
• 내부 속성을 변경하거나 초기화 하기 어려움
• private 생성자로 자식 클래스를 만들기 어려움
• 결론적으로 유연성이 떨어짐
• 안티패턴으로 불리기도 함

 

3. 싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리함
  • 지금까지 우리가 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다 !
• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다 ➡️ 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스 트리라 한다

 

⇒ 스프링 컨테이너 덕분에 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라,

이미 만들어진 객체를 공유해서 효율적으로 재사용 가능

 

4. 싱글톤 방식의 주의점

✅ 싱글톤 주의점

• 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하 게 설계하면 안된다
• 무상태(stateless)로 설계해야 한다!
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!!

 

• StatefulService 의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경함
• 사용자A의 주문금액은 10000원이 되어야 하는데, 20000원이라는 결과가 나왔다.

 

5. @Configuration과 싱글톤

 

✅ 궁금증 : 싱글톤이 깨지는 것 처럼 보인다

• memberService 빈 →  memberRepository() →  new MemoryMemberRepository()
• orderService 빈 →  memberRepository()  →  new MemoryMemberRepository()

 

 

✅ 결과 : 3개 스프링이 모두 동일

 

✅ 확인 : AppConfig에 호출 로그 남김

• 예상 : 총 3번 호출
  1. 스프링 컨테이너가 스프링 빈에 등록하기 위해 @Bean이 붙어있는 memberRepository() 호출 
  2. memberService() 로직에서 memberRepository() 호출
  3. orderService() 로직에서 memberRepository() 호출
• 결과 : 모두 1번만 호출

 

 

6. @Configuration과 바이트코드 조작의 마법

스프링이 자 바 코드까지 어떻게 하기는 어렵다.
저 자바 코드를 보면 분명 3번 호출되어야 하는 것이 맞다.
그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.
모든 비밀은 @Configuration 을 적용한 AppConfig 에 있다

⇒ 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것!