Javaの引数を持つシングルトン

ウィキペディアのシングルトンの記事を読んでいて、この例に出くわしました。

public class Singleton {
    // Private constructor prevents instantiation from other classes
    private Singleton() {}

    /**
     * SingletonHolder is loaded on the first execution of Singleton.getInstance() 
     * or the first access to SingletonHolder.INSTANCE, not before.
     */
    private static class SingletonHolder { 
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

私はこのシングルトンの動作を本当に気に入っていますが、コンストラクターに引数を組み込むためにそれをどのように適応させるかわかりません。これをJavaで行うための好ましい方法は何ですか？このようなことをしなければなりませんか？

public class Singleton
{
    private static Singleton singleton = null;  
    private final int x;

    private Singleton(int x) {
        this.x = x;
    }

    public synchronized static Singleton getInstance(int x) {
        if(singleton == null) singleton = new Singleton(x);
        return singleton;
    }
}

ありがとう！

編集：シングルトンを使用したいという思いから、私は論争の嵐を巻き起こしたと思います。私の動機を説明しましょう。うまくいけば、誰かがより良いアイデアを提案してくれるでしょう。グリッドコンピューティングフレームワークを使用して、タスクを並列で実行しています。一般的に、私はこのようなものを持っています：

// AbstractTask implements Serializable
public class Task extends AbstractTask
{
    private final ReferenceToReallyBigObject object;

    public Task(ReferenceToReallyBigObject object)
    {
        this.object = object;
    }

    public void run()
    {
        // Do some stuff with the object (which is immutable).
    }
}

データへの参照をすべてのタスクに単に渡したとしても、タスクがシリアル化されると、データは何度もコピーされます。私がやりたいのは、すべてのタスクでオブジェクトを共有することです。もちろん、クラスを次のように変更することもできます。

// AbstractTask implements Serializable
public class Task extends AbstractTask
{
    private static ReferenceToReallyBigObject object = null;

    private final String filePath;

    public Task(String filePath)
    {
        this.filePath = filePath;
    }

    public void run()
    {
        synchronized(this)
        {
            if(object == null)
            {
                ObjectReader reader = new ObjectReader(filePath);
                object = reader.read();
            }
        }

        // Do some stuff with the object (which is immutable).
    }
}

ご覧のとおり、ここでも、別のファイルパスを渡しても、最初のパスが渡された後は何も意味がないという問題があります。そのため、回答に掲載されているお店のアイデアが気に入っています。とにかく、runメソッドにファイルを読み込むためのロジックを含めるのではなく、このロジックをシングルトンクラスに抽象化したかったのです。さらに別の例を提供することはしませんが、あなたがそのアイデアを理解してくれることを願っています。私がやろうとしていることを達成するためのよりエレガントな方法についてのアイデアを聞かせてください。ありがとうございました！

私は私のポイントを非常に明確にします：パラメータを持つシングルトンはシングルトンではありません。

シングルトンは、定義上、インスタンス化を1回だけ行うオブジェクトです。パラメーターをコンストラクターにフィードしようとしている場合、シングルトンのポイントは何ですか？

2つのオプションがあります。シングルトンをいくつかのデータで初期化したい場合は、インスタンス化後に次のようにデータをロードできます。

SingletonObj singleton = SingletonObj.getInstance();
singleton.init(paramA, paramB); // init the object with data

シングルトンが実行している操作が繰り返し発生し、毎回異なるパラメーターを使用する場合は、実行中のメインメソッドにパラメーターを渡すこともできます。

SingletonObj singleton = SingletonObj.getInstance();
singleton.doSomething(paramA, paramB); // pass parameters on execution

いずれの場合でも、インスタンス化は常にパラメーターなしになります。そうでなければ、あなたのシングルトンはシングルトンではありません。

さまざまなパラメーターを持つオブジェクトをインスタンス化して再利用するには、ファクトリーのようなものが必要だと思います。これは、同期されたパラメーターを使用するHashMapかConcurrentHashMap、パラメーター（Integer例として）をパラメーター化可能な「シングルトン」クラスにマップすることで実装できます。

代わりに、通常のシングルトンではないクラスを使用する必要がある場合があります（たとえば、パラメーター化されたシングルトンの10.000が必要です）。

このようなストアの例を次に示します。

public final class UsefulObjFactory {

    private static Map<Integer, UsefulObj> store =
        new HashMap<Integer, UsefulObj>();

    public static final class UsefulObj {
        private UsefulObj(int parameter) {
            // init
        }
        public void someUsefulMethod() {
            // some useful operation
        }
    }

    public static UsefulObj get(int parameter) {
        synchronized (store) {
            UsefulObj result = store.get(parameter);
            if (result == null) {
                result = new UsefulObj(parameter);
                store.put(parameter, result);
            }
            return result;
        }
    }
}

それをさらに推し進めるために、Javaはenumパラメータ化されたシングルトンと見なす（または使用する）こともできますが、固定数の静的バリアントしか許可されていません。

ただし、分散が必要な場合 ¹ソリューション、横方向のキャッシングソリューションを検討してください。例：EHCache、Terracottaなど。

おそらく複数のコンピューター上で複数のVMにまたがるという意味で¹。

インスタンス化を取得から分離するために、構成可能な初期化メソッドを追加できます。

public class Singleton {
    private static Singleton singleton = null;
    private final int x;

    private Singleton(int x) {
        this.x = x;
    }

    public static Singleton getInstance() {
        if(singleton == null) {
            throw new AssertionError("You have to call init first");
        }

        return singleton;
    }

    public synchronized static Singleton init(int x) {
        if (singleton != null)
        {
            // in my opinion this is optional, but for the purists it ensures
            // that you only ever get the same instance when you call getInstance
            throw new AssertionError("You already initialized me");
        }

        singleton = new Singleton(x);
        return singleton;
    }

}

その後Singleton.init(123)、たとえばアプリの起動時などに、1回呼び出して設定できます。

一部のパラメーターが必須であることを示す場合は、Builderパターンを使用することもできます。

    public enum EnumSingleton {

    INSTANCE;

    private String name; // Mandatory
    private Double age = null; // Not Mandatory

    private void build(SingletonBuilder builder) {
        this.name = builder.name;
        this.age = builder.age;
    }

    // Static getter
    public static EnumSingleton getSingleton() {
        return INSTANCE;
    }

    public void print() {
        System.out.println("Name "+name + ", age: "+age);
    }


    public static class SingletonBuilder {

        private final String name; // Mandatory
        private Double age = null; // Not Mandatory

        private SingletonBuilder(){
          name = null;
        }

        SingletonBuilder(String name) {
            this.name = name;
        }

        public SingletonBuilder age(double age) {
            this.age = age;
            return this;
        }

        public void build(){
            EnumSingleton.INSTANCE.build(this);
        }

    }


}

その後、次のように作成/インスタンス化/パラメータ化できます。

public static void main(String[] args) {
    new EnumSingleton.SingletonBuilder("nico").age(41).build();
    EnumSingleton.getSingleton().print();
}

" パラメータ付きのシングルトンはシングルトンではありません "ステートメントは完全に正しくありません。これを、コードの観点からではなく、アプリケーションの観点から分析する必要があります。

シングルトンクラスを作成して、1回のアプリケーション実行でオブジェクトの単一インスタンスを作成します。パラメーター付きのコンストラクターを使用することにより、アプリケーションを実行するたびにシングルトンオブジェクトの一部の属性を変更する柔軟性をコードに組み込むことができます。これはシングルトンパターンの違反ではありません。これをコードの観点から見ると、違反のように見えます。

デザインパターンは、柔軟で拡張可能なコードの記述を支援するためのものであり、優れたコードの記述を妨げるものではありません。

ゲッターとセッターを使用して変数を設定し、デフォルトのコンストラクターをプライベートにします。次に使用します：

Singleton.getInstance().setX(value);

ロガーがどのように作成/取得されるかについて誰も言及しなかったことに驚いた。たとえば、以下はLog4Jロガーがどのように取得されるかを示しています。

// Retrieve a logger named according to the value of the name parameter. If the named logger already exists, then the existing instance will be returned. Otherwise, a new instance is created.
public static Logger getLogger(String name)

間接参照にはいくつかのレベルがありますが、重要な部分はメソッドの下にあり、それがどのように機能するかについてほとんどすべてを伝えます。ハッシュテーブルを使用して既存のロガーを格納し、キーは名前から派生します。特定の名前のロガーが存在しない場合、ロガーはファクトリを使用してロガーを作成し、それをハッシュテーブルに追加します。

69   Hashtable ht;
...
258  public
259  Logger getLogger(String name, LoggerFactory factory) {
260    //System.out.println("getInstance("+name+") called.");
261    CategoryKey key = new CategoryKey(name);
262    // Synchronize to prevent write conflicts. Read conflicts (in
263    // getChainedLevel method) are possible only if variable
264    // assignments are non-atomic.
265    Logger logger;
266
267    synchronized(ht) {
268      Object o = ht.get(key);
269      if(o == null) {
270        logger = factory.makeNewLoggerInstance(name);
271        logger.setHierarchy(this);
272        ht.put(key, logger);
273        updateParents(logger);
274        return logger;
275      } else if(o instanceof Logger) {
276        return (Logger) o;
277      } 
...

Bill Pughの初期化オンデマンドホルダーイディオムを使用するシングルトンパターンの変更。これは、特殊な言語構造（つまり、揮発性または同期）のオーバーヘッドがないスレッドセーフです。

public final class RInterfaceHL {

    /**
     * Private constructor prevents instantiation from other classes.
     */
    private RInterfaceHL() { }

    /**
     * R REPL (read-evaluate-parse loop) handler.
     */
    private static RMainLoopCallbacks rloopHandler = null;

    /**
     * SingletonHolder is loaded, and the static initializer executed, 
     * on the first execution of Singleton.getInstance() or the first 
     * access to SingletonHolder.INSTANCE, not before.
     */
    private static final class SingletonHolder {

        /**
         * Singleton instance, with static initializer.
         */
        private static final RInterfaceHL INSTANCE = initRInterfaceHL();

        /**
         * Initialize RInterfaceHL singleton instance using rLoopHandler from
         * outer class.
         * 
         * @return RInterfaceHL instance
         */
        private static RInterfaceHL initRInterfaceHL() {
            try {
                return new RInterfaceHL(rloopHandler);
            } catch (REngineException e) {
                // a static initializer cannot throw exceptions
                // but it can throw an ExceptionInInitializerError
                throw new ExceptionInInitializerError(e);
            }
        }

        /**
         * Prevent instantiation.
         */
        private SingletonHolder() {
        }

        /**
         * Get singleton RInterfaceHL.
         * 
         * @return RInterfaceHL singleton.
         */
        public static RInterfaceHL getInstance() {
            return SingletonHolder.INSTANCE;
        }

    }

    /**
     * Return the singleton instance of RInterfaceHL. Only the first call to
     * this will establish the rloopHandler.
     * 
     * @param rloopHandler
     *            R REPL handler supplied by client.
     * @return RInterfaceHL singleton instance
     * @throws REngineException
     *             if REngine cannot be created
     */
    public static RInterfaceHL getInstance(RMainLoopCallbacks rloopHandler)
            throws REngineException {
        RInterfaceHL.rloopHandler = rloopHandler;

        RInterfaceHL instance = null;

        try {
            instance = SingletonHolder.getInstance();
        } catch (ExceptionInInitializerError e) {

            // rethrow exception that occurred in the initializer
            // so our caller can deal with it
            Throwable exceptionInInit = e.getCause();
            throw new REngineException(null, exceptionInInit.getMessage());
        }

        return instance;
    }

    /**
     * org.rosuda.REngine.REngine high level R interface.
     */
    private REngine rosudaEngine = null;

    /**
     * Construct new RInterfaceHL. Only ever gets called once by
     * {@link SingletonHolder.initRInterfaceHL}.
     * 
     * @param rloopHandler
     *            R REPL handler supplied by client.
     * @throws REngineException
     *             if R cannot be loaded.
     */
    private RInterfaceHL(RMainLoopCallbacks rloopHandler)
            throws REngineException {

        // tell Rengine code not to die if it can't
        // load the JRI native DLLs. This allows
        // us to catch the UnsatisfiedLinkError
        // ourselves
        System.setProperty("jri.ignore.ule", "yes");

        rosudaEngine = new JRIEngine(new String[] { "--no-save" }, rloopHandler);
    }
}

あなたがしようとしていることを達成する方法を理解できない理由は、おそらくあなたがしようとしていることが実際には意味をなさないためです。getInstance(x)異なる引数で呼び出したいが、常に同じオブジェクトを返したいですか？それはあなたが呼び出すときに何をしたいの行動でgetInstance(2)、その後とgetInstance(5)？

同じオブジェクトが必要であるが、その内部値が異なる場合（これがまだシングルトンである唯一の方法である場合）は、コンストラクターをまったく気にする必要はありません。getInstance()オブジェクトの出口に値を設定するだけです。もちろん、シングルトンへの他のすべての参照には、異なる内部値があることを理解しています。

あなたがしたい場合getInstance(2)やgetInstance(5)、他の一方で、異なるオブジェクトを返すために、あなたはFactoryパターンを使用している、Singletonパターンを使用していません。

あなたの例では、シングルトンを使用していません。次のことを実行することに注意してください（Singleton.getInstanceが実際に静的であると想定）。

Singleton obj1 = Singleton.getInstance(3);
Singleton obj2 = Singleton.getInstance(4);

その場合、obj2.xの値は4ではなく3になります。これを行う必要がある場合は、プレーンクラスにします。値の数が少なく固定されている場合は、enum。過度のオブジェクト生成に問題がある場合（通常はそうではありません）、値をキャッシュすることを検討できます（メモリリークの危険なしにキャッシュを構築する方法が明らかであるため、ソースを確認するか、ヘルプを取得してください）。

シングルトンは簡単に使い過ぎる可能性があるため、この記事を読むこともできます。

シングルトンがアンチパターンであるもう1つの理由は、プライベートコンストラクターを使用して推奨事項に従って記述した場合、特定の単体テストで使用するようにサブクラス化して構成することが非常に難しいためです。たとえば、レガシーコードの保守に必要になります。

コンテキストとして機能するシングルトンクラスを作成する場合は、構成ファイルを用意し、instance（）内のファイルからパラメーターを読み取るのが良い方法です。

プログラムの実行中にシングルトンクラスにフィードするパラメーターが動的に取得される場合は、シングルトンクラスにさまざまなインスタンスを格納する静的HashMapを使用して、各パラメーターに対してインスタンスが1つだけ作成されるようにします。

これはシングルトンではありませんが、問題を解決できる可能性があります。

public class KamilManager {

  private static KamilManager sharedInstance;

  /**
   * This method cannot be called before calling KamilManager constructor or else
   * it will bomb out.
   * @return
   */
  public static KamilManager getInstanceAfterInitialized() {
    if(sharedInstance == null)
        throw new RuntimeException("You must instantiate KamilManager once, before calling this method");

    return sharedInstance;
}

  public KamilManager(Context context, KamilConfig KamilConfig) {
    //Set whatever you need to set here then call:
  s  haredInstance = this;
  }
}

「状態を持つシングルトンを作成する方法」として問題を取り上げる場合、状態をコンストラクターパラメーターとして渡す必要はありません。シングルトンインスタンスを取得した後、状態を初期化する、またはsetメソッドを使用する投稿に同意します。

別の質問は、状態を持つシングルトンを持つことは良いことですか？

次のようなことはできませんでした。

public class Singleton {

    private int x;

    // Private constructor prevents instantiation from other classes
    private Singleton() {}

    /**
     * SingletonHolder is loaded on the first execution of Singleton.getInstance() 
     * or the first access to SingletonHolder.INSTANCE, not before.
     */
    private static class SingletonHolder { 
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance(int x) {
        Singleton instance = SingletonHolder.INSTANCE;
        instance.x = x;
        return instance;
    }
}

一部の人が主張するかもしれないにもかかわらず、ここにコンストラクタのパラメータを持つシングルトンがあります

public class Singleton {

    private static String aParameterStored;

    private static final Singleton instance = new Singleton("Param to set");

    private Singleton() {
        // do nothing
    }

    private Singleton(String param) {
        aParameterStored = param;
    }

    public static Singleton getInstance() {
        return instance;
    }

    /*
     * ... stuff you would like the singleton do
     */
}

シングルトンパターンは言う：

• シングルトンクラスのインスタンスが1つだけ存在することを確認する
• そのインスタンスへのグローバルアクセスを提供します。

この例で尊重されています。

プロパティを直接設定しないのはなぜですか？パラメーター付きのコンストラクターを持つシングルトンを取得する方法を示すのは教科書のケースですが、状況によっては役立つ場合があります。たとえば、継承の場合、シングルトンにいくつかのスーパークラスプロパティを強制的に設定します。

これを回答として投稿するのは怖いですが、なぜこれについて誰も考えないのかわかりません。おそらく、この回答もすでに与えられているので、理解できませんでした。

public class example  {
    private volatile static example instance;

    private String string;
    private int iInt = -1; //any number you know you don't want to use here

  private example() {

    //In case someone uses the private method to create a new Instance
    if (instance != null){
      throw new RuntimeException("Use getInstance() method to get the single instance of this class.");
    }
  }

  public synchronized static example getIsntance(){
    if(instance == null){
      instance = new example();
    }
    return instance;
  }

public void methodDoingWork(){
    if(checkInit()){
      //DoSome
    }
  }

  private boolean checkInit(){
    boolean filled = (this.string != null) && (this.iInt != -1);
    return filled;
  }

  public void setString(String string) {
    if(this.string == null){
      this.string = string;
    }else{
      throw new RuntimeException("You try to override an already setValue"); 
    }
  }

  public void setiInt(int iInt) {
    if(this.iInt == -1){
      this.iInt = iInt;
    }else{
      throw new RuntimeException("You try to override an already setValue");
    }
  }
}

はgetInstance()いつも同じインスタンスを返すので、これはうまくいくと思います。これが間違っている場合は削除しますが、このトピックに興味があります。

これはよくある問題だと思います。シングルトンの「初期化」をシングルトンの「取得」から分離すると機能する場合があります（この例では、ダブルチェックロックのバリエーションを使用しています）。

public class MySingleton {

    private static volatile MySingleton INSTANCE;

    @SuppressWarnings("UnusedAssignment")
    public static void initialize(
            final SomeDependency someDependency) {

        MySingleton result = INSTANCE;

        if (result != null) {
            throw new IllegalStateException("The singleton has already "
                    + "been initialized.");
        }

        synchronized (MySingleton.class) {
            result = INSTANCE;

            if (result == null) {
                INSTANCE = result = new MySingleton(someDependency);
            } 
        }
    }

    public static MySingleton get() {
        MySingleton  result = INSTANCE;

        if (result == null) {
            throw new IllegalStateException("The singleton has not been "
                    + "initialized. You must call initialize(...) before "
                    + "calling get()");
        }

       return result;
    }

    ...
}

もちろん、シングルトンは「アンチパターン」です（状態が可変であるstaticの定義を想定）。

不変値オブジェクトの固定セットが必要な場合は、列挙型が適しています。大規模な、場合によってはオープンエンドの値のセットの場合、通常はMap実装に基づく、何らかの形式のリポジトリを使用できます。もちろん、静力学を扱うときは、スレッディングに注意してください（十分に広く同期するConcurrentMapか、別のスレッドが打ち負かしていないことを確認するか、何らかの形式のフューチャーを使用します）。

シングルトンは一般にアンチパターンと見なされ、使用すべきではありません。コードをテストしやすくするものではありません。

引数を持つシングルトンはとにかく意味がありません-あなたが書いた場合どうなるでしょう：

Singleton s = SingletonHolder.getInstance(1);
Singleton t = SingletonHolder.getInstance(2); //should probably throw IllegalStateException

シングルトンもスレッドセーフではありません。複数のスレッドがを同時に呼び出してgetInstance、複数のインスタンスが作成される可能性があるためです（おそらくの値が異なるx）。