기존의 AppConfig
스프링이 없는 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다. (고객 트래픽이 초당 100일 경우, 초당 100개의 객체가 생성되고 소멸된다.) 따라서 메모리 낭비가 심하므로 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 해결 가능하다(싱글톤 패턴).
싱글톤 패턴
클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.
- 객체 인스턴스를 여러 개 생성할 수 없도록 방지해야 한다.
- private 생성자를 사용해 외부에서 임의로 new 키워드를 사용하지 못하도록 한다.
public class SingletonService {
private static final SingletonService instance = new SingletonService();
private SingletonService() {}
public static SingletonService getInstance(){
return instance;
}
}- static 영역에 객체 "instance"를 생성해서 올려둔다.
- 이 클래스에서 인스턴스가 필요할 경우, getInstance( ) 메서드를 통해서만 조회가 가능하다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
DIP 위반 - 싱글톤 패턴이므로 딱 한개의 인스턴스만 존재해야 하므로 생성자를 private로 만들어서 외부에서 new 키워드로 생성할 수 없도록 할 수 있다.
싱글톤 패턴의 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- DIP 원칙 위반, OCP 원칙 위반 가능성 - 의존관계상 클라이언트가 구현 클래스에 의존하게 된다.
- 테스트의 어려움이 있다.
- 내부 속성을 변경하거나 초기화가 어렵다.
- private 생성자를 사용하므로 자식 클래스를 만들기 어렵다.
- 유연성이 떨어진다.
싱글톤 컨테이너
스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하고 객체 인스턴스를 1개만 생성하여 관리한다.
또한 스프링 빈은 싱글톤으로 관리되는 빈이다.(빈을 하나만 생성해서 관리)
- 스프링 컨테이너는 싱글톤을 사용하지 않아도 자동적으로 객체 인스턴스를 싱글톤으로 관리한다.
- 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
싱글톤 레지스트리 : 싱글톤 객체를 생성하고 관리하는 기능- 싱글톤 패턴을 위한 코드가 삽입되지 않아도 되며, DIP, OCP, 테스트와 private인 생성자로 부터 자유롭게 싱글톤 사용이 가능하다.
싱글톤 컨테이너 적용 후
스프링 컨테이너 덕분에, 유저의 요청이 올 때마다 새로운 객체를 생성하는 방식이 아닌 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있게 되었다.
참고
빈 스코프 : 기본 스프링 빈 등록 방식은 싱글톤이지만, 다른 방식들도 지원한다. 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다.
싱글톤 방식의 주의점
객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하므로 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. -> 무상태(stateless)로 설계해야 한다.
- 특정 클라이언트에 의존적인 필드가 있으면 안되고, 값을 변경할 수 있는 필드도 존재하면 안된다.
- 가급적 Read only
- 필드 대신, 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
- 스프링 빈 필드에 공유 값을 설정하면 큰 장애가 발생할 수 있다.
