스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다.
- 여기에서의 싱글톤은 디자인 패턴의 싱글톤 패턴과 비슷하지만 구현 방법이 다름!
왜 스프링은 싱글톤으로 빈을 만드는가?
스프링은 대규모 엔터프라이즈 서버환경에서 많이 이용.
매번 클라이언트에서 요청이 올 때마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용한다면, 아무리 GC의 성능이 좋아졌어도 부하가 걸리면 서버가 감당하기 힘들다.
디자인 패턴에서의 싱글톤 패턴과 그 한계
싱글톤 패턴
: 어떤 클래스를 애플리케이션 내에서 제한된 인스턴스 개수, 주로 하나만 존재하도록 강제하는 패턴. 이렇게 하나만 만들어지는 클래스의 오브젝트는 애플리케이션 내에서 전역적으로 접근이 가능하다. 단일 오브젝트만 존재해야 하고, 이를 어플리케이션의 여러 곳에서 공유하는 경우에 주로 사용한다.
싱글톤 패턴 한계
- private 생성자를 갖고 있기 때문에 상속할 수 없다.
- 싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못하다.
- 싱글톤은 사용하는 클라이언트가 정해져 있지 않다. 싱글톤의 static 메서드를 이용해 언제든지 쉽게 접근할 수 있으므로 애플리케이션 어디서든지 사용될 수 있고, 그러다보면 자연스럽게 전역 상태로 사용되기 쉽다.
- 아무 객체나 자유롭게 접근하고 수정하고 공유할 수 있는 전역 상태를 갖는 것은 객체지향 프로그래밍에서 권장되지 않는다.
싱글톤 레지스트리
자바의 기본적인 싱글톤 패턴의 구현 방식은 여러 가지 단점이 있기 때문에,
스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다.
=> 싱글톤 레지스트리
스프링 컨테이너는 싱글톤을 생성, 관리, 공급하는 싱글톤 관리 컨테이너이기도 하다.
싱글톤 레지스트리 장점
- 평범한 자바 클래스를 싱글톤으로 활용하게 해준다.
- 싱글톤 방식으로 사용될 애플리케이션 클래스라도 public 생성자를 가질 수 있다.
싱글톤과 오브젝트의 상태
싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다.
-> 상태 관리에 주의를 기울여야 한다.
싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에
상태정보를 내부에 가지고 있지 않은 무상태(stateless)방식으로 만들어져야 한다.
다중 사용자의 요청을 한꺼번에 처리하는 스레드들이 동시에 싱글톤 오브젝트의 인스턴스 변수를 수정하는 것은 매우 위험.
저장할 공간이 하나뿐이라 서로 값을 덮어쓰고 자신이 저장하지 않은 값을 읽어올 수 있기 때문!
-> 각 요청에 대한 정보나 리소스로부터 생성한 정보는 파라미터, 로컬 변수, 리턴 값 등을 이용한다. 메서드 안에서 생성되는 지역 변수는 매번 새로운 값을 저장할 독립적인 공간이 만들어지기 때문에 싱글톤이라 해도 여러 스레드가 변수의 값 덮어쓸 일 없다.
토비의 스프링
