웹 어플케이션에서 여러 고객이 요청을 할 때마다
DI컨테이너는 새로운 객체를 생성하게 됨
=> 트래픽이 클수록 더 많은 객체 생성과 소멸 반복 == 메모리부하
=> 싱글톤의 필요성
싱글톤 패턴 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 길다
- 의존관계상 클라이언트가 구체 클래스에 의존해야 함 -> DIP X
- OCP위반 가능성 높음
- 테스트하기 어려움
- 내부 속성을 변경하거나 초기화하기 어려움
- private 생성자로 자식클래스 만들기 어려움
- 결론적으로 유연성 떨어짐
- 안티패턴으로 불리기도 한다.
스프링 컨테이너는 알아서 싱글톤으로 객체를 관리함
스프링 컨테이너는 객체를 하나만 생성해서 싱글톤 객체로 빈을 관리하는 싱글톤 레지스트리 역할을 함.
설사 하나의 빈 생성자가 여러번 호출될 것 같은 상황에서도 싱글톤을 유지함 -> CGLIB라는 라이브러리를 통해 AppConfig클래스를 상속받은 임의의 다른 클래스를 만들고, 그 클래스를 스프링 빈으로 등록함. 실제로 내가 만든 객체를 인스턴스로 만드는게 아니라는 것.
그래서 AppConfig의 @Configuration을 제거하면
생성자가 중복해서 호출되는 것을 확인할 수 있음
(Test.ConfigurationSingletonTest 확인)
+싱글톤 방식의 주의점
- 읽기만 가능해야 함 : 여러 클라이언트가 한 객체 인스턴스를 공유하기 때문에 특정 클라이언트에 의존적이거나 특정 클라이언트가 수정할 수 있는 필드가 있으면 안됨
- 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용
