싱글톤 패턴, 싱글톤 레지스트리

싱글톤 패턴(Singleton Pattern)

• 어떤 클래스를 애플리케이션 내에서 제한된 인스턴스 개수, 이름처럼 주로 하나만 존재하도록 강제하는 패턴이다.
• 클래스 밖에서는 오브젝트를 생성하지 못하도록 생성자를 private으로 만든다. 
• 생성된 싱글톤 오브젝트를 저장할 수 있는 자신과 같은 타입의 스태틱 필드를 정의한다.
• 스태틱 팩토리 메소드인 getInstance()를 만들고 이 메소드가 최초로 호출되는 시점에서 한 번만 오브젝트가 만들어지게 한다. 생성된 오브젝트는 스태틱 필드에 저장된다. 또는 스태틱 필드의 초기값으로 오브젝트를 미리 만들어둘 수도 있다.
• 한번 오브젝트(싱글톤)가 만들어지고 난 후에는 getInstance() 메소드를 통해 이미 만들어져 스태틱 필드에 저장해둔 오브젝트를 넘겨준다.

싱글톤 패턴의 한계

• 싱글톤 클래스 자신만이 자기 오브젝트를 만들도록 제한(private 생성자)하기 때문에 상속이 불가능하다.
• 오브젝트를 다이내믹하게 주입하기 어려우므로 테스트하기 힘들다.
• 서버환경에서는 클래스 로더에 따라 싱글톤이 보장되지 않을 수도 있다.
• 싱글톤은 사용하는 클라이언트가 정해져 있지 않기 때문에 싱글톤의 스태틱 메소드를 통해 어디서든지 사용될 수 있고 이는 전역 상태로 사용되기 쉽다는 것을 의미한다.

"아무 객체나 자유롭게 접근하고 수정하고 공유할 수 있는 전역 상태를 갖는 것은 객체지향 프로그래밍에서는 권장되지 않는 프로그래밍 모델이다." (p108) // 우리 서비스가 생각난다.

싱글톤 레지스트리(Singleton Registry)

스프링은 스태틱 메소드와 private 생성자가 없는 평범한 자바 클래스를 싱클톤으로 활용하게 해준다. 스프링은 IoC 컨테이너이면서 싱글톤을 만들고 관리해주는 싱글톤 레지스트리이다.

싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태정보를 내부에 갖고 있지 않은 무상태(stateless) 방식으로 만들어져야 한다. 저장할 공간이 하나뿐이니 서로 값을 덮어쓰고 자신이 저장하지 않은 값을 읽어올 수 있기 때문이다.

파라미터와 로컬 변수, 리턴 값을 이용하여 여러 스레드가 변수의 값을 덮어쓸 일이 없도록 하자.

// 우리 서비스는 진정 stateless 한가? 엄청 많은 사람들이 동시에 이용하기 때문에 stateful 한다면 문제가 이미 발생하긴 했을 것 같은데... 전역 변수 사용하는 클래스가 하나도 없었나? reqChunk도 싱클톤 같은 객체도 유지되나? (reqChunk는 빈이 아닌 오브젝트였나?) 그럼 우리 서비스 처럼 여러 개의 서버가 돌아가고 있는 상황에서도 빈은 딱 하나만 존재한다는 말인가?