소스코드내에는 몇가지 싱글톤 구현방법이 나옵니다. 그 각각이 의미하는바는 다음과 같습니다.
1) EagerSingleton
static class EagerSingleton extends Singleton {
static final EagerSingleton theInstance = new EagerSingleton();
static EagerSingleton getInstance() {
return theInstance;
}
}
이 경우는 미리 싱글톤 인스턴스를 생성하는 방법으로 static final 필드에
인스턴스를 생성하여 할당하는 방법입니다. 이 필드는 클래스로더에 의해서
EagerSingleton이 메모리로 올라오는 순간에 안전하게(thread-safe하게)초기화
됩니다. 이 방법이 아마 성능이 가장 우수하게 나타날 것입니다.
장점은 동기화부담이 적다는 것입니다. 단 한번 클래스로더가 thread-safe하게
클래스를 로드하는 시점에 클래스가 로딩되어 안전합니다. 단점은 인스턴스가
미리부터 생성된다는 것입니다.
2) SynchedSingleton
static class SynchedSingleton extends Singleton {
static SynchedSingleton theInstance;
static synchronized SynchedSingleton getInstance() {
if (theInstance == null)
theInstance = new SynchedSingleton();
return theInstance;
}
}
이 방법은 싱글톤 필드에 접근할때마다 동기화를 수행하는 방법입니다. 매번
동기화를 수행하므로 자바 메모리 모델에 따른 각종 문제를 방지할 수 있어
thread-safe합니다. 단점은 매번동기화를 수행하므로 수행 비용이 높다는
것입니다.
3) ThreadLocalSingleton
static class ThreadLocalSingleton extends Singleton {
static final ThreadLocal perThreadInstance = new ThreadLocal();
static final Object lock = new Object();
static ThreadLocalSingleton theInstance;
static ThreadLocalSingleton getInstance() {
ThreadLocalSingleton instance = (ThreadLocalSingleton)(perThreadInstance.get());
if (instance == null) {
synchronized(lock) {
instance = theInstance;
if (instance == null)
instance = theInstance = new ThreadLocalSingleton();
}
// copy global to per-thread
perThreadInstance.set(instance);
}
return instance;
}
}
이 방법은 Thread Local Storage를 사용한 해법입니다. 자바 쓰레드 메모리 모델에서
문제가 발생하는 것은 멀티 CPU상황에서 각각의 CPU가 자신의 캐시내에 클래스의
필드를 복사해넣는다는 것입니다. 이러한 캐시는 메인메모리와 동기화가 되어
있지 않습니다. 즉, 각각의 CPU가 하나의 클래스를 접근하게되면 각각의 CPU는
그 클래스의 내용을 다르게 볼 수 있다는 것입니다. 싱글톤을 구현하면 instance라는
필드를 여러개의 CPU가 참조하는데 이 필드를 여러개의 CPU가 다르게 보게 됩니다.
예를들어 CPU A가 인스턴스를 생성하고 생성한 인스턴스를 instance에 할당한다고
합시다. 그러면 CPU A가 또다시 이 instance 필드를 참조할때는 생성된 인스턴스를
제대로 보게 됩니다. 그러나 CPU B가 이 instance필드를 참조할때는 instance필드가
null로 나타날 수 있습니다. 그 이유는 CPU A가 수행한 작업은 synchronized블록을
통과할때까지 메인메모리에 반영이 안되고 자신의 캐시내에만 담겨 있을 수 있으며,
CPU B역시 synchornized블록을 통과하지 않으면 메인메모리가 아닌 자신의 캐시만
들여다보기 때문입니다.
이를 해결하려면 각각 CPU가 동기화블록을 들어갔다가 나와야만 하는데,
이를 구현한 것이 위의 코드입니다. 각각의 Thread는 자신만의 메모리공간으로서
TLS(Thread Local Storage)를 가지고 있으며 이들은 매 쓰레드마다의 공간이므로
동기화될 필요가 없습니다. 따라서 이 저장소에 해당 쓰레드가 synchronized블록을
한번이라도 다녀왔는지(한번이라도 다녀오면 CPU가 메인메모리의 값을 가져오니까요)를
저장해둡니다.
4) SimulatedThreadLocalSingleton
static class SimulatedThreadLocalSingleton extends Singleton {
static SimulatedThreadLocalSingleton theInstance;
static final Object lock = new Object();
static final Object key = new Object();
static Singleton getInstance() {
TSS t = (TSS)(Thread.currentThread());
Singleton instance = (Singleton)(t.threadLocalHashtable.get(key));
if (instance == null) {
synchronized(lock) {
instance = theInstance;
if (instance == null)
instance = theInstance = new SimulatedThreadLocalSingleton();
}
// copy global to per-thread
t.threadLocalHashtable.put(key, instance);
}
return instance;
}
}
이 방법은 TLS를 ThreadLocal 클래스를 쓰지 않고 직접구현한 방식입니다.
5) VolatileSingleton
static class VolatileSingleton extends Singleton {
static final Object lock = new Object();
static volatile VolatileSingleton theInstance;
static VolatileSingleton getInstance() {
VolatileSingleton instance = theInstance;
if (instance == null) {
synchronized(lock) {
instance = theInstance;
if (instance == null)
instance = theInstance = new VolatileSingleton();
}
}
return instance;
}
}
주의!)이 방법은 절대로 사용해서는 안됩니다.
이 방법은 volatile를 사용합니다. volatile 로 선언된 필드는 매번 원자적으로
쓰레드 safe하게 이루어집니다. 즉 각각의 변수에 대한 접근이 매번 메인메모리와
동기화될 뿐만아니라, thread safe하게 이루어집니다. synchronized와 volatile은
이처럼 변수의 접근마다 동기화를 하느냐 아니면 특정 블록을 통채로 동기화
하는냐의 문제에 있어서 접근방법이 틀립니다. 그러나 아쉽게도 volatile은
대부분의 자바 컴파일러에서 제대로 구현되어있지않으며 따라서 사용하는것을
권하지 않습니다. SUN의 컴파일러는 제대로 되지 않느냐 하고 생각하실 수 있지만
전혀 안그렇습니다. SUN의 JDK 1.3대에서도 제대로 구현이 되어있지 않습니다.
volatile은 동기화의 문제를 비롯한 다양한 암시적 작동이 보장되어야하는데
이를 제대로 책임지고 않기때문입니다.
6) DirectThreadFieldSingleton
static class DirectThreadFieldSingleton extends Singleton {
static DirectThreadFieldSingleton theInstance;
static final Object lock = new Object();
static Singleton getInstance(TSS t) {
Singleton instance = t.singleton;
if (instance == null) {
synchronized(lock) {
instance = theInstance;
if (instance == null)
instance = theInstance = new DirectThreadFieldSingleton();
}
// copy global to per-thread
t.singleton = instance;
}
return instance;
}
}
인스턴스를 할당받고자하는 쪽에서 TSS라는 형태의 클래스를 쓰레드마다 할당한채로
갖고 있다가 이것을 싱글톤 클래스에 넘깁니다. 그러면 TSS.singleton변수의
값을가지고 동기화 수행여부를 결정하는 방식입니다. ThreadLocal의 변형이며,
모든 인스턴스를 획득하고자하는 쓰레드가 TSS를 넘겨야한다는 점에서
좋은 방법은 아니겠죠.
7) ThreadFieldSingleton
static class ThreadFieldSingleton extends Singleton {
static final Object lock = new Object();
static ThreadFieldSingleton theInstance;
static Singleton getInstance() {
TSS t = (TSS)(Thread.currentThread());
Singleton instance = t.singleton;
if (instance == null) {
synchronized(lock) {
instance = theInstance;
if (instance == null)
instance = theInstance = new ThreadFieldSingleton();
}
// copy global to per-thread
t.singleton = instance;
}
return instance;
}
}
이 방법역시 ThreadLocal의 구현에 대한 변형된 구현입니다. ThreadLocal 대신,
특정 싱글톤 클래스에 대한 인스턴스를 획득하려고 시도하는 쓰레드를 캐스팅해서
ThreadLocal을 구현한 것이죠. 개인적으로 이 방법은 별로 좋지 않다고봅니다.
특정 클래스의 인스턴스를 획득하려면 쓰레드가 어떠한 인스턴스를 구현하고
있는지는 쉽사리 가정하기가 곤란하죠.
