일반적으로, 메모리에 하나의 Instance만 로딩되도록 해야 하는 경우 Singleton Pattern을 적용한 Singleton Class를 사용한다.
<3> Lazy Initialization
하지만, 대용량의 트래픽이 발생하는 Concurrent Request 환경에서는 하나의 Request가 곧 하나의 Thread를 실행하게 된다. 그런 경우, Singleton Class는 Thread-Safe하지 않게 될 수 있다.
원치 않게 각 요청에 따른 올바른 Response를 주지 못하고, 데이터가 꼬여 다른 결과를 리턴하게 되는 치명적인 결과가 초래될 수 있다.
모든 경우와 같이, Singleton Class를 제공하는 경우에도 다음과 같은 고려가 필요하다.
- 동시에 여러 개의 요청이 오더라도 순서대로 처리할 수 있어야 한다.
- 최대한의 성능을 고려해야 한다.
- 여러 요청으로 인해 병목이 발생하더라도 다른 작업을 처리하고 있는 Thread에 영향을 최소화해야 하고, 프로그램이 종료되지 않아야 한다.
Singleton Class 구현 방법은 다음과 같은 방법으로 생각해 볼 수 있다.
<1> Eager Initialization
package com.dev.sampleClass Loading 시점에 Singleton Class Instance가 생성된다. 가장 쉽게 Signleton Class를 생성하는 방법이지만, Client에서 요청이 없을 때에도 항상 생성되므로 불필요한 리소스를 사용하게 된다. 또한 대부분 파일 시스템이나 데이터베이스에 접속하는 경우 Singleton Class를 사용하는데 Exception을 처리할 수 없다.
public class EagerInitSingleton {
private static final EagerInitSingleton = new EagerInitSingleton();
private EagerInitSingleton () {}
public static EagerInitSingleton getInstance() {
return instance;
}
}
<2> Static Block Initialization
package com.dev.sample
public class StaticBlockSingleton {
private static StaticBlockSingleton instance;
private StaticBlockSingleton () {}
static {
try {
instance = new StaticBlockSingleton();
}
catch (Exception e) {
throw new RuntimeException(e.printStackTrace());
}
}
public static StaticBlockSingleton getInstance() {
return instance;
}
}
Static Block은 Eager Initialization Singleton과 비슷하게 Class Loading 시점에 Static Block 안에서 Singleton 객체가 생성되지만, Exception을 처리할 수 있다. 하지만, 동일한 단점을 가지고 있다.
package com.dev.sampleSingle Thread 환경에서 잘 동작한다. 하지만, 동시에 여러 개의 Thread가 접근할 경우 여러 개의 Instance가 생성될 수 있다. 그런 경우 Singleton Pattern이 깨지고, 서로 다른 Singleton Instance를 사용하게 될 수 있다.
public class LazyInitSingleton {
private static LazyInitSingleton instance;
private LazyInitSingleton() {}
public static LazyInitSingleton getInstance() {
if (instance == null) {
instance = new LazyInitSingleton();
}
return instance;
}
}
<4> Thread-Safe Singleton
package com.dev.samplesynchronized 키워드를 사용하여 한번에 하나의 Thread만 호출할 수 있도록 만들 수 있다. 하지만 모든 Thread의 요청에 대해 synchronized를 실행하므로 성능상 오버헤드가 발생한다.
public class ThreadSafeSingleton {
private static ThreadSafeSingleton instance;
private ThreadSafeSingleton() {}
public static synchronized ThreadSafeSinfleton getInstance() {
if (instance == null) {
instance = new ThreadSafeSingleton();
}
return instance;
}
}
<5> Double Checked Thread-Safe Singleton
package com.dev.sample위와 같은 Double Checked Locking 원리를 이용하면, 조건을 만족시키는 경우 (instance == null) 한 번만 synchronized block이 실행되므로 하나의 Singleton Class Instance만 생성된다. synchronized로 인한 성능 이슈를 해소할 수 있다.
public class DoubleCheckThreadSafeSingleton {
private static DoubleCheckThreadSafeSingleton instance;
private DoubleCheckThreadSafeSingleton() {}
public static DoubleCheckThreadSafeSingleton getInstance() {
if(instance == null) {
synchronized (DoubleCheckThreadSafeSingleton.class) {
if (instance == null) {
instance = new DoubleCheckThreadSafeSingleton();
}
}
}
return instance;
}
}
<6> On-demand Holder Idiom에 따른 Inner Class(holder or helper class)를 이용한 Singleton
package com.dev.samplegetInstance() method를 호출 할 때, SingletonHelper 클래스가 생성되고 Singleton intance는 static final 키워드로 인해 한번만 생성된다. 대부분 <6>번의 경우를 많이 사용한다.
public class HelperSingleton {
private HelperSingleton() {}
private static class SingletonHelper {
private static final HelperSingleton instance = new HelperSingleton();
}
public static HelperSingleton getInstance() {
return SingletonHelper.instance;
}
}
Comments