Singleton mit Argumenten in Java

Ich habe den Singleton-Artikel auf Wikipedia gelesen und bin auf dieses Beispiel gestoßen:

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;
    }
}

Obwohl mir das Verhalten dieses Singleton sehr gut gefällt, kann ich nicht sehen, wie ich es anpassen kann, um Argumente in den Konstruktor aufzunehmen. Was ist der bevorzugte Weg, dies in Java zu tun? Würde ich so etwas tun müssen?

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;
    }
}

Vielen Dank!

Bearbeiten: Ich glaube, ich habe mit meinem Wunsch, Singleton zu verwenden, einen Sturm der Kontroversen ausgelöst. Lassen Sie mich meine Motivation erklären und hoffentlich kann jemand eine bessere Idee vorschlagen. Ich verwende ein Grid-Computing-Framework, um Aufgaben parallel auszuführen. Im Allgemeinen habe ich so etwas:

// 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).
    }
}

Obwohl ich lediglich einen Verweis auf meine Daten an alle Aufgaben weitergebe, werden die Daten bei der Serialisierung der Aufgaben immer wieder kopiert. Ich möchte das Objekt auf alle Aufgaben verteilen. Natürlich könnte ich die Klasse so ändern:

// 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).
    }
}

Wie Sie sehen können, habe ich auch hier das Problem, dass das Übergeben eines anderen Dateipfads nichts bedeutet, nachdem der erste übergeben wurde. Aus diesem Grund gefällt mir die Idee für ein Geschäft, das in den Antworten veröffentlicht wurde. Anstatt die Logik zum Laden der Datei in die Ausführungsmethode aufzunehmen, wollte ich diese Logik in eine Singleton-Klasse abstrahieren. Ich werde kein weiteres Beispiel nennen, aber ich hoffe, Sie haben die Idee. Bitte lassen Sie mich Ihre Ideen für einen eleganteren Weg hören, um das zu erreichen, was ich versuche. Danke nochmal!

Ich werde meinen Standpunkt sehr deutlich machen: Ein Singleton mit Parametern ist kein Singleton .

Ein Singleton ist per Definition ein Objekt, das Sie nur einmal instanziieren möchten. Wenn Sie versuchen, dem Konstruktor Parameter zuzuführen, wozu dient der Singleton?

Sie haben zwei Möglichkeiten. Wenn Sie möchten, dass Ihr Singleton mit einigen Daten initialisiert wird, können Sie ihn nach der Instanziierung wie folgt mit Daten laden :

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

Wenn die Operation, die Ihr Singleton ausführt, wiederkehrend ist und jedes Mal andere Parameter aufweist, können Sie die Parameter auch an die auszuführende Hauptmethode übergeben:

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

In jedem Fall ist die Instanziierung immer parameterlos. Andernfalls ist Ihr Singleton kein Singleton.

Ich denke, Sie brauchen so etwas wie eine Fabrik , um Objekte mit verschiedenen Parametern instanziieren und wiederverwenden zu lassen. Es könnte implementiert werden, indem ein synchronisierter HashMapoder ConcurrentHashMapein Parameter ( Integerzum Beispiel ein) Ihrer parametrierbaren 'Singleton'-Klasse zugeordnet wird.

Obwohl Sie möglicherweise an den Punkt gelangen, an dem Sie stattdessen reguläre Nicht-Singleton-Klassen verwenden sollten (z. B. 10.000 unterschiedlich parametrisierte Singleton-Klassen).

Hier ist ein Beispiel für ein solches Geschäft:

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;
        }
    }
}

Um es noch weiter enumvoranzutreiben, können die Java s auch als parametrisierte Singletons betrachtet (oder als solche verwendet) werden, obwohl nur statische Varianten mit einer festen Anzahl zulässig sind.

Wenn Sie jedoch eine verteilte ^1- Lösung benötigen, sollten Sie eine laterale Caching-Lösung in Betracht ziehen. Zum Beispiel: EHCache, Terrakotta usw.

¹ im Sinne einer Spannweite mehrerer VMs auf wahrscheinlich mehreren Computern.

Sie können eine konfigurierbare Initialisierungsmethode hinzufügen, um die Instanziierung vom Abrufen zu trennen.

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;
    }

}

Dann können Sie Singleton.init(123)einmal anrufen , um es zu konfigurieren, zum Beispiel beim Start Ihrer App.

Sie können auch das Builder-Muster verwenden, wenn Sie zeigen möchten, dass einige Parameter obligatorisch sind.

    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);
        }

    }


}

Dann können Sie es wie folgt erstellen / instanziieren / parametrisieren :

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

Die Anweisung " Ein Singleton mit Parametern ist kein Singleton " ist nicht vollständig korrekt . Wir müssen dies eher aus der Anwendungsperspektive als aus der Codeperspektive analysieren.

Wir erstellen eine Singleton-Klasse, um eine einzelne Instanz eines Objekts in einem Anwendungslauf zu erstellen. Mit einem Konstruktor mit Parametern können Sie Ihrem Code Flexibilität hinzufügen, um einige Attribute Ihres Singleton-Objekts bei jeder Ausführung Ihrer Anwendung zu ändern. Dies ist keine Verletzung des Singleton-Musters. Es sieht nach einer Verletzung aus, wenn Sie dies aus Code-Sicht sehen.

Design Patterns sollen uns helfen, flexiblen und erweiterbaren Code zu schreiben, und uns nicht daran hindern, guten Code zu schreiben.

Verwenden Sie Getter und Setter, um die Variable festzulegen und den Standardkonstruktor privat zu machen. Dann benutze:

Singleton.getInstance().setX(value);

Überrascht, dass niemand erwähnt hat, wie ein Logger erstellt / abgerufen wird. Im Folgenden wird beispielsweise gezeigt, wie der Log4J-Logger abgerufen wird.

// 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)

Es gibt einige Ebenen von Indirektionen, aber der Schlüsselteil befindet sich unter der Methode, die so ziemlich alles darüber erzählt, wie es funktioniert. Es verwendet eine Hash-Tabelle, um die vorhandenen Logger zu speichern, und der Schlüssel wird vom Namen abgeleitet. Wenn der Logger für einen Vornamen nicht vorhanden ist, verwendet er eine Factory, um den Logger zu erstellen, und fügt ihn dann der Hash-Tabelle hinzu.

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      } 
...

Änderung des Singleton-Musters unter Verwendung der Red Pugh-Initialisierung bei Bedarf . Dies ist threadsicher ohne den Aufwand spezialisierter Sprachkonstrukte (dh flüchtig oder synchronisiert):

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);
    }
}

Der Grund, warum Sie nicht verstehen können, wie Sie das erreichen, was Sie versuchen, ist wahrscheinlich, dass das, was Sie versuchen, keinen wirklichen Sinn ergibt. Sie möchten getInstance(x)mit unterschiedlichen Argumenten aufrufen , aber immer das gleiche Objekt zurückgeben? Welches Verhalten möchten Sie, wenn Sie anrufen getInstance(2)und dann getInstance(5)?

Wenn Sie möchten, dass dasselbe Objekt unterschiedlich ist, der interne Wert jedoch unterschiedlich ist. Nur so ist es immer noch ein Singleton. Dann müssen Sie sich überhaupt nicht um den Konstruktor kümmern. Sie setzen den Wert einfach getInstance()auf dem Weg des Objekts ein. Natürlich verstehen Sie, dass alle anderen Verweise auf den Singleton jetzt einen anderen internen Wert haben.

Wenn Sie möchten , getInstance(2)und getInstance(5)verschiedene Objekte zurückzukehren, auf der anderen Seite, die Sie verwenden nicht die Singleton - Muster, sind Sie die Fabrik Muster.

In Ihrem Beispiel verwenden Sie keinen Singleton. Beachten Sie Folgendes: Wenn Sie Folgendes tun (vorausgesetzt, Singleton.getInstance war tatsächlich statisch):

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

Dann ist der Wert von obj2.x 3, nicht 4. Wenn Sie dies tun müssen, machen Sie es zu einer einfachen Klasse. Wenn die Anzahl der Werte klein und fest ist, können Sie eine verwenden enum. Wenn Sie Probleme mit einer übermäßigen Objektgenerierung haben (was normalerweise nicht der Fall ist), können Sie Caching-Werte in Betracht ziehen (und Quellen überprüfen oder Hilfe dazu erhalten, da es offensichtlich ist, wie Caches ohne die Gefahr von Speicherlecks erstellt werden).

Vielleicht möchten Sie diesen Artikel auch lesen, da Singletons sehr leicht überbeansprucht werden können.

Ein weiterer Grund, warum Singletons ein Anti-Pattern sind, besteht darin, dass sie, wenn sie gemäß den Empfehlungen mit einem privaten Konstruktor geschrieben wurden, sehr schwer zu klassifizieren und für die Verwendung in bestimmten Komponententests zu konfigurieren sind. Wäre zum Beispiel für die Pflege von Legacy-Code erforderlich.

Wenn Sie eine Singleton-Klasse erstellen möchten, die als Kontext dient, sollten Sie eine Konfigurationsdatei haben und die Parameter aus der Datei in instance () lesen.

Wenn die Parameter, die die Singleton-Klasse speisen, während der Ausführung Ihres Programms dynamisch abgerufen werden, verwenden Sie einfach eine statische HashMap, in der verschiedene Instanzen in Ihrer Singleton-Klasse gespeichert sind, um sicherzustellen, dass für jeden Parameter nur eine Instanz erstellt wird.

Dies ist kein Einzelfall, kann aber möglicherweise Ihr Problem beheben.

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;
  }
}

Wenn wir das Problem als "wie man Singleton mit state macht" betrachten, ist es nicht notwendig, den state als Konstruktorparameter zu übergeben. Ich bin mit den Posts einverstanden, die die Zustände initialisieren oder die set-Methode verwenden, nachdem die Singleton-Instanz abgerufen wurde.

Eine andere Frage ist: Ist es gut, Singleton mit Staat zu haben?

Könnten wir so etwas nicht machen:

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;
    }
}

Trotz allem, was einige behaupten mögen, ist hier ein Singleton mit Parametern im Konstruktor

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
     */
}

Das Singleton-Muster sagt:

• Stellen Sie sicher, dass immer nur eine Instanz der Singleton-Klasse vorhanden ist
• Bieten Sie globalen Zugriff auf diese Instanz.

die mit diesem Beispiel respektiert werden.

Warum nicht direkt die Eigenschaft einstellen? Es ist ein Lehrbuchfall, um zu zeigen, wie wir einen Singleton mit einem Konstruktor mit Parameter erhalten können, aber es kann in einigen Situationen nützlich sein. Zum Beispiel in Vererbungsfällen, um den Singleton zu zwingen, einige Eigenschaften der Oberklasse festzulegen.

Ich habe Angst, dies als Antwort zu posten, aber ich verstehe nicht, warum niemand darüber nachdenkt. Vielleicht wurde diese Antwort auch schon gegeben, ich habe sie einfach nicht verstanden.

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");
    }
  }
}

Da die getInstance()Instanz jedes Mal dieselbe Instanz zurückgibt, denke ich, dass dies funktionieren könnte. Wenn dies zu viel falsch ist, werde ich es löschen, ich bin nur an diesem Thema interessiert.

Ich denke, das ist ein häufiges Problem. Das Trennen der "Initialisierung" des Singletons vom "Get" des Singletons funktioniert möglicherweise (in diesem Beispiel wird eine Variante der doppelt aktivierten Sperre verwendet).

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;
    }

    ...
}

Singleton ist natürlich ein "Anti-Pattern" (unter der Annahme einer Definition einer Statik mit variablem Zustand).

Wenn Sie einen festen Satz unveränderlicher Wertobjekte wünschen, sind Aufzählungen der richtige Weg. Für einen großen, möglicherweise offenen Satz von Werten können Sie ein Repository in irgendeiner Form verwenden - normalerweise basierend auf einer MapImplementierung. Wenn Sie sich mit Statik beschäftigen, sollten Sie natürlich vorsichtig mit dem Threading umgehen (entweder ausreichend breit synchronisieren oder ConcurrentMapentweder überprüfen, ob ein anderer Thread Sie nicht geschlagen hat, oder irgendeine Form von Futures verwenden).

Singletons gelten allgemein als Anti-Patterns und sollten nicht verwendet werden. Sie machen es nicht einfach, Code zu testen.

Ein Singleton mit einem Argument macht sowieso keinen Sinn - was würde passieren, wenn Sie schreiben würden:

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

Ihr Singleton ist auch nicht threadsicher, da mehrere Threads gleichzeitig aufrufen können, getInstancewas dazu führt, dass mehr als eine Instanz erstellt wird (möglicherweise mit unterschiedlichen Werten von x).