Bean Scope
: Bean Definition을 만들 때 해당 bean definition에 의해 정의된 클래스의 실제 인스턴스를 만들기 위한 레시피를 만든다. (빈이 존재할 수 있는 범위를 의미한다.)
- bean의 정의에서 생성된 개체에 연결할 다양한 의존성 밀 구성값 뿐만 아니라 특정 bean 정의에서 생성된 개체의 범위도 제어할 수 있다.
- Spring Framework는 6개의 범위를 지원하고, 그 중 4개는 ApplicationContext를 사용하는 경우에만 사용할 수 있다.
- bean은 여러 범위 중 하나에 배치되도록 정의할 수 있다.
- 구성을 통해 생성하는 개체의 범위를 선택할 수 있기 때문에 강력하고 유연하다.
- 사용자 정위 범위를 생성할 수도 있다.
Singleton Scope
: 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
- 스프링 컨테이너의 시작과 함께 생성되어 스프링 컨테이너가 종료될 때까지 유지된다.
- 싱글톤 빈의 하나의 공유 인스턴스만 관리하게 된다.(private 생성자를 사용해 외부에서 임의로 new를 사용하지 못하도록 막아야 한다.)
- 해당 bean definition와 일치하는 ID 또는 ID를 가진 빈에 대한 모든 요청은 스프링 컨테이너에서 해당 특정 빈 인스턴스를 반환한다.
- 스프링 컨테이너 종료 시 소멸 메서드도 자동으로 실행된다.
싱글톤은 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것이다.
단일 인스턴스는 싱글톤 빈의 캐시에 저장된다.
이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 개체를 반환한다.(싱글톤 스코프의 스프링 빈은 여러 번 호출해도 모두 같은 인스턴스 참조 주소값을 가진다.)
bean 하나에 하나씩 메타 정보가 생성되고, 스프링 컨테이너는 이런 메타 정보를 기반으로 스프링 빈을 생성한다.
싱글톤 패턴의 문제점
- 싱글톤 패턴을 구현하는 코드가 많다.
- 의존 관계상 클라이언트가 구체 클래스에 의존한다.
- 지정해서 가져오기 때문에 테스트하기 어렵다.
- private 생성자를 사용하여 자식 클래스를 만들기 때문에 유연성이 떨어진다.
- 속성 공유(멀티 쓰레드 환경에서 싱글톤 객체의 속성은 여러 쓰레드에 의해 바뀔 수 있다. A쓰레드에서는 속성 값을 x로 바꾸고 출력하는 과정에서 B 쓰레드가 속성값을 y로 바꾸면 쓰레드 A에선 예상하지 못한 값이 나올 수 있다. -> 1개의 인스턴스에서 속성값을 공유하기 때문에 발생하는 문제점이다. 가급적 읽기만 가능해야 한다.)
- Application 초기 구동 시 인스턴스를 생성한다. (싱글톤 빈은 기본적으로 애플리케이션 구동 시 생성되므로 싱글톤 빈이 많을수록 구동시간이 증가할 수 있다.)
싱글톤 패턴 문제를 싱글톤 컨테이너가 해결해준다.
: 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 싱글톤 객체로 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다. 스프링 컨테이너의 위 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하며 객체를 싱글톤으로 유지할 수 있다.
싱글톤 방식의 주의점
: 싱글톤 방식은 여러 클라이언트기 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 무상태로 설계해야 한다. -> 특정 클라이언트가 값을 변경할 수 있으면 안된다. 읽기만 가능해야 한다. 스프링 빈의 공유값을 설정하면 장애가 발생할 수밖에 없다.
- 스프링 컨테이너에서 빈 스코프의 기본값은 싱글톤 스코프이다.
- 싱글톤 패턴을 사용할 때 발생하는 문제점을 싱글톤 컨테이너로 해결할 수 있다.
개발 공부하는 일상