싱글톤 패턴이던 스프링 같은 싱글톤 컨테이너를 사용하던, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 즉, 무상태(stateless)로 설계해야 한다. 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야 한다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal...등을 사용해야 한다. 스프링 빈의 필드에 공유 값을 설정하면 큰 장애가 발생할 수 있다.
싱글톤 컨테이너에 대해 알아보자. 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 우리가 학습한 스프링 빈이 싱글톤으로 관리되는 빈이다. 싱글톤 컨테이너 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 이전에 설명한 컨테이너 생성 과정을 보면 컨테이너 객체를 하나만 생성해서 관리한다. 즉, 스프링 컨테이너는 싱글톤 컨테이너 역할을 하는 것이다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다. 스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다. 다음과 같은 테스트코드를 작성해 직접 확인해보자. @Test @Display..
이번 포스팅부터는 싱글톤 컨테이너에 대해 알아보자. 싱글톤 패턴은 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴하는 것을 말한다. 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다. 그래서 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 할 수 있다. 웹 애플리케이션은 보통 여러 클라이언트가 동시에 요청을 한다. 위 상황에서 클라이언트가 3번의 요청을 하면 3개의 객체가 생성된다. 이렇게 되면 요청이 올 때마다 계속 객체를 생성해야 하는 문제가 발생한다. 이를 코드를 이용해 테스트를 해보자. 다음은 스프링을 사용하지 않은 DI 컨테이너이다. ..