스프링 컨테이너와 스프링 빈

스프링 빈 등록

1. 컨테이너 생성
    컨테이너 생성할 때 AppConfig.class를 넘긴다.
2. 빈 등록
    AppConfig에 @Bean 붙은 애들이 다 빈으로 등록된다.
   이름 - 값 형태로 등록됨
3. 의존관계 주입

 

싱글톤 컨테이너

사용자가 요청을 할 때 마다 객체를 생성하면 메모리 낭비가 심하다.
→ 해당 객체가 딱 1개만 생성되고 공유하도록 설계
⇒ 싱글톤 패턴

 

싱글톤 패턴

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

 

→ private 생성자를 사용해 외부에서 임의로 new 키워드 사용 못하도록 막아야 한다.

적용방법

// 1. static 영역에 객체를 미리 하나 생성해서 올려둔다.
private static final SingletonService instance = new SingletonService();

// 2. 이 객체 인스턴스가 필요하면 오직 getInstance () 를 통해서만 조회 가능. 
// 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
public static SingletonService getInstance() {
    return instance;
}

 

객체를 생성하는데 드는 비용이 1000 정도라면 참조로 가져오는 비용은 1정도로 생각할 수 있음. 하지만 싱글톤 패턴은 많은 단점을 가지고 있다. 스프링 컨테이너는 싱글톤이 가진 단점은 다 제거하면서 객체는 싱글톤으로 관리해준다.

 

스프링 컨테이너

스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.

 

동작

@Configuration을 붙이면 CGLIB 기술(순수한 클래스가 아닌 AppConfig를 상속받은 임의의 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록. 내부적으로는 매우 복잡)을 사용해 싱글톤 보장해줌.

 

스프링 컨테이너가 @Bean이 붙은 메서드마다 이미 빈으로 등록되어 있으면 존재하는 빈을 반환, 없으면 생성해서 빈으로 등록하고 반환한다. (빈 생성 시점)

@Bean만 사용하면 스프링 빈으로 등록은 되지만 싱글톤 보장 안되고 일반 자바코드처럼 동작함. → new 한것처럼 계속 생성.
=> 스프링 설정 정보는 항상 @Configuration을 사용하자.