1.4장에서 직접 만든 DaoFactory와 스프링의 애플리케이션 컨텍스트는 중요한 차이점이 있다.
DaoFactory의 userDao( ) 메소드를 두번 호출해서 리턴되는 2개의 UserDao 오브젝트를 비교해보자.
이 두개는 당연히 다른 오브젝트 이다. 왜냐하면 오브젝트 생성시 할당받는 고유값이 서로 다르기 때문이다.
스프링의 애플리케이션 컨텍스트의 getBean( ) 메소드를 두번 호출하여 userDao라는 이름으로 등록된 오브젝트를 2번 가져와보자.
이 두개는 고유값이 동일하다.
애플리케이션 컨텍스트는 IoC방식으로 빈을 관리하면서 동시에 싱글톤을 저장하고 관리하는 싱글통 레지스트리이기도 하다.
스프링은 기본 설정을 변경하지 않을 시, 모든 빈 오브젝트를 싱글톤으로 만든다.
여기서 싱글톤은 디자인 패턴의 싱글톤 패턴과 비슷한 개념이지만 구현 방법은 확연히 다르다.
스프링은 왜 싱글톤으로 빈을 만드는 것일까?
스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버 환경이기 때문이다.
대규모의 엔터프라이즈 서버 환경을 서버 하나당 최대로 초당 수백번의 리퀘스트를 받고 처리한다.
그런데 이때, 매 요청마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용 시 서버에 부하가 걸린다.
따라서 서버환경에서는 싱글톤 패턴의 사용이 권장된다.
하지만, 디자인 패턴에 소개된 싱글톤 패턴은 사용하기가 까다롭고 여러 문제점이 있다.
자바에서 싱글톤을 구현하는 방법은 보통 이렇다.
일반적으로 싱글톤 패턴 구현 방식에는 다음과 같은 문제가 있다.
pricate 생성자를 갖고 있기 때문에 상속할 수 없다.
싱글톤은 테스트하기가 힘들다.
서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.
스프링은 서버 환경에서 싱글톤이 만들어져서 서비스 오브젝트 방식으로 사용되는 것은 적극 지지한다.
정의
장점
평범한 클래스 (static 메소드나 pricate 생성자를 사용하지 않는)를 싱글톤 방식으로 사용되게 해준다.
싱글톤 패턴과 달리 스프링이 지지하는 객체지향적인 설계 방식과 원칙, 디자인 패턴 등을 적용하는데 아무런 제약이 없다.
스프링 = IoC 컨테이너 + 싱글톤 레지스트리 라는 점을 기억해두자.
다음은 싱글톤으로 만들어지기 때문에 주의해야 할 점에 대해 알아보자.
싱글톤은 멀티스레드 환경이라면, 여러 스레드가 동시에 접근해서 사용할 수 있다.
다중 사용자의 요청을 한꺼번에 처리하는 스레드들이 동시에 싱글톤 오브젝트의 인스턴스 변수를 수정하는 것은 매우 위험하다.
따라서 싱글톤은 기본적으로 인스턴스 필드의 값을 변경하고 유지하는 상태유지 방식으로 만들지 않는다.
정의
종류