태그 보관물: Singleton Pattern

싱글톤 패턴(Singleton Pattern)

아래는 싱글톤(Singleton) 패턴을 구현하는 몇 가지 방법이고, 개별 방법이 가지는 문제에 대해서 살펴보자.

1. EagerSingleton

static class EagerSingleton extends Singleton { 
    static final EagerSingleton theInstance = new EagerSingleton(); 
    static EagerSingleton getInstance() { 
        return theInstance; 
    } 
}

이 경우는 미리 싱글톤 인스턴스를 생성하는 방법으로 static final 필드에 인스턴스를 생성하여 할당하는 방법이다. 이 필드는 클래스로더에 의해서 EagerSingleton이 메모리로 올라오는 순간에 안전하게(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)를 가지고 있고, TLS는 개별 스레드가 가지는 공간으로 동기화가 필요 없다. 따라서 이 저장소에 해당 스레드가 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;
  }
}

이 방법은 ThreadLocal 클래스를 쓰지 않고 TLS를 직접 구현한 방식입니다.

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로 선언된 필드는 매번 원자적으로 스레드 안전하게 동작한다. 즉 개별 변수에 대한 접근이 매번 메인메모리와 동기화 되기에 스레드 안전하게 동작한다. synchronized와 volatile은 이처럼 변수의 접근마다 동기화를 하느냐 아니면 특정 블록을 통채로 동기화 하는냐의 문제에 대한 접근방법이다. 그러나 아쉽게도 volatile은 대부분의 자바 컴파일러에서 제대로 구현되어있지않으며 따라서 사용하는것을 권하지 않는다.

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을 구현한 것이다. 개인적으로 이 방법도 좋지 않다고 본다. 특정 클래스의 인스턴스를 획득하는데 스레드가 특정 인스턴스를 구현하고 있는지는 쉽게 가정하기 어렵기 때문이다.