싱글턴(Singleton) 패턴은 1995년 발간된 소프트웨어 개발 고적 서적 Design Patterns 통하여 세상에 알려지게 되었다.
오랜동안 많은 개발자들이 사용을 즐겼지만 2000년 중반부터 코드를 망가트리는 원인으로 주목을 받으며 안티패턴(Anti-Pattern)의 하나로 간주되고 있다.
다음은 싱글톤에 대한 증오를 보여주는 초장기(온라인에서 검색가능한) 블로그 글이다.
오랜 기간동안 안티 패턴으로 간주되고 있지만 아니러니(irony) 그 편리함으로 인하여 많은 개발자들에 의하여 사용되고 있다.
싱글턴 패턴(Singleton) 이란 ?
싱글턴은 인스턴스가 하나뿐인 객체를 만들 수 있게 해주는 디자인 패턴으로 클래스 디자인 관점에서 보면 아주 간단해보이지만 구현하는 데 있어서는 쉽지않은 장애물들이 있다.
“싱글턴 패턴은 해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접근할 수 있도록 하는 패턴이다.”“Singletons are classes which have a restriction to have only one instance.”
다음 코드는 단일 인스턴스 객체를 구현하는 고전적인 싱글턴 코드이다.
public class Singleton {
// ❸ 유일한 인스턴스 저장을 위한 변수
private static Singleton instance ;
// ❷ 외부에서 인스턴스 생성이 불가하게 생성자를 private 로 선언
private Singleton (){ }
// ❶ Singleton 클래스 인스턴스를 생성하여 리턴.
public static Singleton getInstance (){
if(instance == null ){
instance = new Singleton();
}
return instance ;
}
}
동시성(Concurrency) 문제
간단하게 테스트 코드를 만들어 실행해보았다.
import java.lang.reflect.Constructor;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class SingletonTest {
public static void main(String[] args) {
new SingletonTest().test();
}
private static Logger log = LoggerFactory.getLogger(SingletonTest.class);
public void test() {
System.out.println("start sigleton test.");
new MultiThread("thread01").start();
new MultiThread("thread02").start();
new MultiThread("thread03").start();
};
public class MultiThread extends Thread {
private String name;
public MultiThread(String name) {
this.name = name;
}
public void run() {
int count = 0;
for(int i=0; i<5; i++) {
Singleton singleton = Singleton.getInstance();
System.out.println( name + " : " + singleton.toString());
try {
Thread.sleep(400);
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
}
① Earger Initialzation
public class Singleton {
private static Singleton instalnce = new Singleton() ; // ❷ 유일한 인스턴스를 처음부터 생성
private Singleton (){ // ❶ 외부에서 인스턴스 생성이 불가하게 생성자를 private 로 선언
}
public static Singleton getInstance (){ // ❸ Singleton 클래스 인스턴스를 리턴.
return instance ;
}
}
② Thread-Safe Initialzation (Lazy Initialzation)
인스턴스를 생성하는 getInstance 함수를 동기화처리하여 멀티스레딩 이슈를 해결할 수도 있다. 동기화는 많은 비용이 발생하며 보통 100배 정도의 성능 저하가 있다고 한다.
public class Singleton {
private static Singleton instalnce ; // ❷ 유일한 인스턴스 저장을 위한 변수
private Singleton (){ // ❶ 외부에서 인스턴스 생성이 불가하게 생성자를 private 로 선언
}
public static synchronized Singleton getInstance (){ // ❸ Singleton 클래스 인스턴스를 리턴. (인스턴스가 필요할 때 생성.)
if( instance == null )
instance = new Singleton();
return instance ;
}
}
③ Thread-Safe Initialzation (Lazy Initialzation) : DCL(Double-Checking Locking)
동기화 비용 절감을 위하여 메소드가 아닌 객체를 생성하는 부분에 DCL(Double-Checking Locking) 기법을 적용하는 방법도 있다. DCL 은 실재 객체가 필요할 때 까지 객체를 생성(초기화) 하는 것을 지연하기 위한 디자인이다. 이들 통화여 프로그램을 더 빠르게 실행할 수 있게 된다.
public class Singleton {
private volatile static Singleton instance ; // ❸ 유일한 인스턴스 저장을 위한 변수
private Singleton (){ // ❷ 외부에서 인스턴스 생성이 불가하게 생성자를 private 로 선언
}
public static Singleton getInstance (){ // ❶ Singleton 클래스 인스턴스를 생성하여 리턴.
if( instance == null ) {
synchronized( Singleton.class ) { // 객체를 생성하는 부분만 동기화를 적용한다.
instance = new Singleton();
}
}
return instance ;
}
}
엔지니어(Senior Software Engineer) Peter Haggar(haggar@us.ibm.com)가 2002년 5월에 발표한 Double-Checked Locking and the Singleton Pattern이라는 글이 있다.
그는 이 글에서 자신이 2000년 2월에 출간한 『Practical Java Programming Language Guide』에서 소개한 DCL이 잘못되었으며, 왜 잘못되었는지를 알려주고 있다.
이 같은 오류는 Peter Haggar뿐만 아니라 Allen Holub의 『Taming Java Threads』에서도 발견된다.
Allen Holub 역시 JavaWorld에서 DCL에 대한 자신의 생각이 틀렸으며, 왜 사용해서는 안되는지, 그렇다면 올바른 방식은 무엇인지를 소개하고 있다.
여기에서 알 수 있듯이 현재 출간되어 있는 대부분의 자바 스레드 책들중에 DCL을 다룬 책들은 모두 잘못되었다는 것을 알 수 있다.
많은 자바 프로그래머들이 DCL을 해결하기 위해 내놓은 것중에 하나가 volatile 을 사용하는 것이다. volatile 키워드로 선언된 변수의 의미는 운영 체제, 멀티 스레드 등에 의해 프로그램에서 수정될 수 있다는 것이다.
이에 대한 내용은 Peter Haggar의 Double-checked Locking and the Singleton Pattern에 자세히 설명되어 있으며 여기에 잠시 인용하면 아래와 같은 문제가 있다. JLS(Java Language Specification)을 참고할 때, 변수가 volatile로 선언되면 실행 순서가 일관적인 것으로 여겨지며, 재배치(reordering)이 일어나지 않는다. Peter Haggar은 두 가지 문제를 지적하고 있다.
- 첫번째는 순서 일관성의 문제가 아니라 최적화를 통해 코드가 옮겨지는 문제(reordering),
- 두번째는 많은 JVM이 volatile에 대한 순서 일관성조차 제대로 구현하고 있지 않다.
앞의 내용을 좀더 쉽게 설명하면 이렇다.
단일 스레드 환경에서 프로그램과 메모리의 상호 작용은 비교적 간단하게 보인다. 프로그램은 생성된 객체를 특정 메모리위치에 저장하고 다음에 해당 메모리 위치를 검사하면 그 객체는 계속 존재할 것으로 예상한다.
우리는 프로그램은 코드에 지정된 순서에 따라 순차적으로 실행된다고 생각하지만 진실은 컴파일러, 프로세서, 캐시는 계산 결과에 영향을 미치지 않는 한 프로그램 및 데이터에 대해 모든것을 자유롭게 사용할 수 있다. 예를 들어 컴파일러는 프로그램 코드와 다른 순서로 명령어를 생성 하고 변수를 메모리가 아닌 레지스터에 저장할 수 있다. 또한 프로세스는 명령을 병렬로 순서없이 실행할 수 있다. 그리고 캐시는 변수 값이 주메모리에 저장되는 순서를 변경할 수 있다. JMM(Java Memory Model) 에 따르면 이러한 다양한 재정렬 및 최적화는 프로그램의 실행 결과가 동일한 결과를 얻는 한 모두 가능하다고 한다.
JMM(Java Memory Model) 고려하면 Lock 을 이용한 싱글턴 구현은 volatile 키워드를 사용하더라도 동시성 문제를 (corherency problem) 유발시킬수 있다.
public class Singleton {
private volatile static Singleton instance ; // ❸ 유일한 인스턴스 저장을 위한 변수
private Singleton (){ // ❷ 외부에서 인스턴스 생성이 불가하게 생성자를 private 로 선언
}
public static Singleton getInstance (){ // ❶ Singleton 클래스 인스턴스를 생성하여 리턴.
Singleton instanceToUse = instance ;
if( instanceToUse != null ) { // First check (no locking)
return instanceToUse ;
}
synchronized( this ) { // 객체를 생성하는 부분만 동기화를 적용한다.
if( instance == null ) // second checking (with locking)
instance = new Singleton();
return instance ;
}
}
}
그러나 위의 코드 역시 단일객체생성을 보장하지는 못한다. 코드를 좀더 분석해보면 아래와 같다.
- Thread 1은 getInstance() 메소드로 들어간다.
- Thread 1은 synchronized 블록으로 들어간다. instance가 null이기 때문이다.
- Thread 1은 ❶ ❷ non-null 인스턴스를 만든다. 생성자를 실행하기 전이다.
- Thread 1은 thread 2에 선점된다.
- Thread 2는 인스턴스가 null인지를 점검한다. null이 아니기 때문에, thread 2는 instance 레퍼런스를 (부분적으로 초기화된 Singleton 객체)를 리턴한다.
- Thread 2는 thread 1에 선점된다.
- Thread 1은 ❷ 생성자를 실행함으로서 Singleton 객체의 초기화를 완료하고 레퍼런스를 리턴한다.
④ Lazy Initialization. LazyHolder(Thread-safe)
관용구 "initialization on demand holder" 을 바탕으로 하는 Bill Pugh Singleton 은 가장 많이 사용하는 싱글턴 구현방식으로 volatile 나 synchronized 키워드 없이도 동시성 문제를 해결하고 있기 때문에 가장 우수한 성능을 보여준다.
public class Singleton {
private static Singleton instance ;
private Singleton (){ }
private static class Holder(){
private static final Singleton instance = new Singleton();
}
public static Singleton getInstance (){
return Holder.instance ;
}
}
import java.lang.reflect.Constructor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class SingletonTest {
public static void main(String[] args) {
new SingletonTest().test();
}
private static Logger log = LoggerFactory.getLogger(SingletonTest.class);
public void test() {
System.out.println("start sigleton test.");
Singleton instance = Singleton.getInstance();
log.debug("sigleton instance : " + instance.hashCode());
Singleton instance2 = null;
try {
Constructor[] cstr = Singleton.class.getDeclaredConstructors();
for (Constructor constructor: cstr) {
constructor.setAccessible(true);
instance2 = (Singleton) constructor.newInstance();
break;
}
} catch (Exception e) {
System.out.println(e);
}
log.debug("sigleton instance : " + instance2.hashCode());
};
}
⑤ Lazy Initailization. Enum(Thread-safe)
Reflection 이슈를 극복하기 위하여 Joshua Bloch 가 싱글턴을 구현에 Enum 사용을 제안한 방법이다. Enum 자체가 Thread-safe하기 때문에 스레드(Thread)를 고려한 코드가 요구되지 않는다.
public enum Singleton {
INSTANCE;
}
싱글턴의 문제
싱글턴이 처음 소개되었는 시대와 다르게 프로그램은 더 커지고 복잡해졌다. 개발 팀 규모는 더 커졌고 자동화된 테스트가 일반화되었다. 아마도 싱글턴 패턴의 남용과 오용이 난무했을 것이다. 많은 개발자들의 사랑을 받았던 싱글터은 이제 안티 패턴으로 불리고 있다.
싱클턴 페턴은 어려 문제를 해결하면서 다양한 구현 방법이 고안되어 진화하고 있다.
- 싱글턴에 의존하는 객체는 테스트를 위한 분리가 매우 어렵다.
- 코드들이 매우 강하게 연결되어 있어 재구성이 어렵다. (싱글턴은 인테페이스가 아닌 구현 클래스를 미리 생성하고 정적 함수를 이용하여 인스턴스에 접근하기 때문에 구조적으로 높은 결합도를 갖는다.)
- 참조되는 모든 클래스를 수정해야 하기 때문에 전역 객체(싱글턴)에서 비전역 객체로 변경이 어렵다.
남용으로 인한 싱글턴(모든 전역 참조 객체)의 부작용은 코드의 강한 결합에 따라 코드 리팩토링이 어렵고 자동화된 테스트 적용이 어렵다는 점이 가장 큰 이유일 것이다.
싱글턴 문제 해결하기
싱글턴 패턴에서 자동화된 테스트가 가능하고 프로그램 변경이 유연한 아키텍처를 갖게하려면 어떻게 해야할까? 아래와 같은 방법을 생각할 수 있다.
- 객체 생성에 대한 책임이 개체 자신이 되면 않된다.
- 싱글턴을 참조하는 클래스는 직접적인 강한 연결이 되면 않된다.(구현 클래스를 직접 참조하는 것을 의미)
스프링 프레임워크는 싱글턴 구현을 위하여 전통적인 static 키워드가 아닌 DI(Dependency Injection) 접근 방식을 사용하고 있다.
전역(싱글턴) 객체을 참조하는 클래스들이 생성될 떄 자동으로 전역 객체를 주입하는 방식을 적용하는 것인데 이를 통하여 자동화 테스트가 가능하고 객체 의존성을 최소화하는 싱글턴 구현이 가능하다.
참고자료
- 『Head First Design Patterns』
- Singleton Pattern Pitfalls
- Your wrong about singletons
- Singleton Pattern Pitfalls
- How to solve the “Double-Checked Locking is Broken” Declaration in Java?
- Double-checked locking: Clever, but broken
- Singletons: Bill Pugh Solution or Enum
- Design Patterns in the Spring Framework
댓글 없음:
댓글 쓰기