[토비의 스프링] 싱글톤 레지스트리, 빈 스코프

📚 토비의 스프링 3.1 vol.1 102pg ~ 110pg

---

📍 오브젝트의 동일성과 동등성

동일성

• 두 개의 오브젝트가 완전히 동일
• 동일성 비교 (Identity)
• == 연산자로 비교

동등성 

• 오브젝트의 정보가 동일
• 동등성 비교 (Equality)
• equals() 메서드로 비교

---

📍 싱글톤 패턴

싱글톤 패턴

• 애플리케이션 안에 제한된 인스턴스 개수, 주로 한 개만 존재하도록 강제하는 패턴
• 단일 오브젝트만 존재해야 함
• 애플리케이션의 여러 곳에서 공유하는 경우 주로 사용

한계

1️⃣ private 생성자를 가지고 있기에 상속 불가 

• 싱글톤은 자기 자신만 오브젝트를 만들도록 생성자를 private으로 제한
• private 생성자를 가진 클래스는 다른 생성자가 없다면 상속이 불가
• 다형성 적용 불가
• 스태틱 필드와 메서드를 사용하는 것도 동일한 문제(상속 불가, 다형성 적용 불가)를 발생 시킴

2️⃣ 테스트가 힘듦 

• 테스트용 목 오브젝트 등으로 대체가 어려움

3️⃣ 서버 환경에서 싱글톤이 하나만 만들어지는 것을 보장 할 수 없음

• 서버에서 클래스 로더를 어떻게 구성하느냐에 따라 하나 이상의 오브젝트가 만들어 질 수 있음
• 여러 개의 JVM에 분산되어 설치되는 경우에도 각각 독립적으로 오브젝트가 생성되므로 싱글톤으로서의 가치 하락

4️⃣싱글톤의 사용은 전역 상태를 만들 수 있기에 바람직하지 못함

• 싱글톤을 사용하는 클라이언트가 정해져 있지 않음
• 스태틱 메서드를 이용해 쉽게 접근 가능
• 때문에 자연스럽게 전역 상태로 사용되기 쉬움
• 아무 객체나 자유롭게 접근하며, 수정하고 공유할 수 있는 전역 상태는 객체지향에서 권장하지 않음

---

📍 싱글톤 레지스트리

싱글톤 레지스트리

• 스프링은 별다른 설정이 없다면, 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만듦
• 스프링은 싱글톤 형태의 오브젝트를 만들고 관리하는 기능 제공
• 스프링 컨테이너는 싱글톤을 생성하고, 관리하고, 공급하는 "싱글톤 관리 컨테이너" 이기도 함

장점

• public 생성자를 가질 수 있음
• 테스트 환경에서 자유롭게 오브젝트를 만들 수 있으며, 목 오브젝트로 대체하는 것도 간단
• 싱글톤 패턴 외의 다른 디자인 패턴 적용에 제약 없음

주의할 점

🚨 멀티 스레드 환경이라면 상태 관리에 주의 필요

• 멀티 스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우, 상태 정보를 내부에 가지고 있지 않은 무상태(stateless) 방식으로 만들어저야 함
• 값을 덮어쓰거나 저장하지 않은 값을 읽어올 수 있음

---

📍 스프링 빈 스코프

스프링 빈 스코프

• 빈이 생성되고 존재하고 적용되는 범위
• 기본 스코프는 싱글톤

싱글톤 스코프 

• 컨테이너 내 한개의 오브젝트만 만들어져서, 강제로 제거하지 않는 한 스프링 컨테이너가 존재하는 동안 유지

싱글톤 외 스코프

📎 프로토 타입 스코프

• 컨테이너에 빈을 요청할 때마다 새로운 오브젝트 생성

📎  요청 스코프

• 웹을 통해 새로운 HTTP 요청이 생길 때마다 생성

📎 세션 스코프

• 웹의 세션과 스코프가 유사

---