GoF 책에는 싱글톤 패턴을 “클래스가 인스턴스를 하나만 갖게 하고 전역 범위에서 이 인스턴스에 접근하는 단일 지점을 제공하기 위해” 사용한다고 적혀있습니다. 헤드 퍼스트 책도 별반 다르지 않습니다. 싱글톤은 보통 팩토리와 함께 곁들여 씁니다(6장 팩토리 패턴에서 다시 설명합니다).

싱글톤의 주된 쓰임새는,

• 애플리케이션 도메인 전역에서 설정 데이터 등 공유 데이터에 접근한다.

• 값비싼 리소스를 한 번만 읽고 캐시하여 전역 범위에서 접근 가능한 지점을 공유하고 성능을 높인다.

• 유일한 애플리케이션 로거 인스턴스를 생성한다(하나만 필요).

• 팩토리 패턴을 구현한 클래스 내부에서 객체를 관리한다.

• 유일한 퍼사드 객체를 생성한다(하나만 필요).

• 정적 클래스를 뒤늦게(lazily) 생성한다(싱글톤은 나중에 인스턴스화할 수 있음).

 

스프링은 싱글톤으로 빈을 생성하고(스프링 빈은 싱글톤이 기본입니다) 자바 EE는 서비스 위치자(service locator) 등에 내부적으로 싱글톤을 씁니다. 자바 SE 런타임 클래스 구현체에도 싱글톤 패턴을 사용합니다. 싱글톤은 올바르게 사용하면 아주 큰 도움이 됩니다.

하지만 싱글톤을 남용하면 쓸데없이 리소스를 캐시하고 가비지 컬렉터가 객체를 회수하지 못해 쓸 수 있는 메모리 리소스가 줄어듭니다. 또 싱글톤을 사용한다는 자체가 객체의 생성과 상속의 이점을 모두 포기하는 걸 의미합니다. 싱글톤을 비정상적으로 과도하게 사용한 코드는 부실한 객체 지향 설계를 방증하며 나중에 메모리, 성능 문제가 불거질 수 있습니다. 단위 테스트에도 싱글톤은 별로 좋지 않습니다. 싱글톤 패턴 사용상 문제점은 잠시 후 자세히 살펴보지요.