静的変数がたくさんある静的クラスはちょっとしたハックです。
/**
* Grotty static semaphore
**/
public static class Ugly {
private static int count;
public synchronized static void increment(){
count++;
}
public synchronized static void decrement(){
count--;
if( count<0 ) {
count=0;
}
}
public synchronized static boolean isClear(){
return count==0;
}
}
実際のインスタンスを持つシングルトンの方が優れています。
/**
* Grotty static semaphore
**/
public static class LessUgly {
private static LessUgly instance;
private int count;
private LessUgly(){
}
public static synchronized getInstance(){
if( instance==null){
instance = new LessUgly();
}
return instance;
}
public synchronized void increment(){
count++;
}
public synchronized void decrement(){
count--;
if( count<0 ) {
count=0;
}
}
public synchronized boolean isClear(){
return count==0;
}
}
状態はインスタンス内でのみです。
したがって、シングルトンを後で変更して、プーリングやスレッドローカルインスタンスなどを実行できます。また、メリットを得るために、すでに記述されているコードを変更する必要はありません。
public static class LessUgly {
private static Hashtable<String,LessUgly> session;
private static FIFO<LessUgly> freePool = new FIFO<LessUgly>();
private static final POOL_SIZE=5;
private int count;
private LessUgly(){
}
public static synchronized getInstance(){
if( session==null){
session = new Hashtable<String,LessUgly>(POOL_SIZE);
for( int i=0; i < POOL_SIZE; i++){
LessUgly instance = new LessUgly();
freePool.add( instance)
}
}
LessUgly instance = session.get( Session.getSessionID());
if( instance == null){
instance = freePool.read();
}
if( instance==null){
// TODO search sessions for expired ones. Return spares to the freePool.
//FIXME took too long to write example in blog editor.
}
return instance;
}
静的クラスで同様のことを行うことは可能ですが、間接ディスパッチでは呼び出しごとのオーバーヘッドが発生します。
インスタンスを取得して、引数として関数に渡すことができます。これにより、コードを「正しい」シングルトンに送ることができます。必要になるのは1つだけです...必要がなくなるまで。
大きな利点は、ステートフルシングルトンをスレッドセーフにすることができるのに対し、静的クラスは、シークレットシングルトンに変更しない限りできないことです。