인프런 김영한 강사님의 스프링 핵심원리 강의를 듣고 정리하고자 한다
오늘의 주제는 싱글톤 컨테이너이다.
싱글톤 패턴
스프링 애플리케이션은 대부분 웹 애플리케이션이고, 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 그런데 요청을 할 때마다 새로운 객체가 생성된다면 어떻게 될까 ? 요즘에는 하드웨어 성능이 좋아서 괜찮지만 그래도 메모리 낭비가 심하다는 단점이 있다. 이를 해결하는 방법은 해당 객체가 1개만 생성되고, 공유하도록 설계하면 된다. 이를 싱글톤 패턴이라고 한다.
정리하면 싱글톤 패턴은
- 클래스의 인스턴스가 딱 1개만 생성되는 것이 보장되는 패턴
- 객체 인스턴스가 2개 이상 생성하지못하게 해야함
만드는 방법은 다음과 같다.
- static 영역에 객체 instance를 미리 한 개 생성
- 이 instance가 필요하면 getInstance() 메소드를 통해서만 조회 가능. 이 메소드를 호출하면 항상 같은 인스턴스반환
- 생성자를 private으로 해서 외부에서 new 키워드로 객체가 생성되는거 막기
이렇게 하면 호출할 때마다 같은 객체가 반환된다!
하지만 싱글톤 패턴을 구현할 때 코드가 많이 들어가고, 클라이언트가 구체 클래스에 의존하여 DIP를 위반한다는 문제점이 있다. 또한 테스트나 내부 속성을 변경, 초기화가 어려워 유연성이 떨어진다는 문제들이 있다. 이런 문제점을 해결하면서 싱글톤으로 관리해주는 것이 스프링 컨테이너이다.
싱글톤 컨테이너
스프링 컨테이너가 싱글톤 패턴의 문제점을 해결하는 동시에 싱글톤으로 객체를 관리한다. 스프링 빈이 싱글톤으로 관리되는 빈인 것이다!
- 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체를 싱글톤으로 관리함
- 스프링 컨테이너가 싱글톤 컨테이너 역할을 한다. 이런 기능을 싱글톤 레지스트리라고 함
이런 기능 덕에 싱글톤 패턴의 모든단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
# 싱글톤 패턴을 위한 지저분한 코드 필요X
# DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용 가능
싱글톤 방식의 주의점 🌟
싱글톤 방식은 여러 클라이언트가 하나의 같은 객체를 공유하므로 상태를 유지하게 설계하면 안된다.
즉, 무상태로 설계해야한다.
- 특정 클라이언트에 의존적인 필드 있으면 X
- 특정 클라이언트가 값을 변경할 수 있는 필드 있으면 X
즉 수정할 수 없게, 읽기만 가능하게 해야한다.
@Configuration 또한 싱글톤을 보장해준다!! AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링으로 자동 등록되므로 AppConfig도 스프링 빈이 된다.
'백엔드 > 스프링' 카테고리의 다른 글
[Spring] 5. 빈 생명주기 콜백- 스프링 핵심원리 기본편 (1) | 2024.02.09 |
---|---|
[Spring] 4. 자동으로 의존관계 주입하기 - 스프링 핵심원리 기본편 (2) | 2024.02.07 |
[Spring] 2. 스프링으로 전환하기 (스프링 빈, 스프링 컨테이너) - 스프링 핵심원리 기본편 (1) | 2024.02.05 |
[Spring] 1. 순수 자바로 설계하기 - 스프링 핵심원리 기본편 (1) | 2024.01.29 |
[Spring] 0. 객체지향설계와 스프링 (0) | 2024.01.28 |