Le pattern Singleton avec la combinaison de chargement paresseux et le fil de sécurité

J'ai été faire quelques recherches sur les singletons, spécialement en ce qui concerne paresseux vs désireux d'initialisation de singletons.

Un exemple de désireux de l'initialisation:

public class Singleton
{
    //initialzed during class loading
    private static final Singleton INSTANCE = new Singleton();

    //to prevent creating another instance of Singleton
    private Singleton(){}

    public static Singleton getSingleton(){
        return INSTANCE;
    }
}

mais, comme indiqué ci-dessus qu'il est désireux d'initialisation et le fil de sécurité est laissée à la jvm
mais maintenant, je veux avoir ce même modèle, mais avec l'initialisation tardive.

donc je venir avec cette approche: 

public final class Foo {
    private static class FooLoader {
        private static final Foo INSTANCE = new Foo();
    }
    private Foo() {
        if (FooLoader.INSTANCE != null) {
            throw new IllegalStateException("Already instantiated");
        }
    }
    public static Foo getInstance() {
        return FooLoader.INSTANCE;
    }
}

Comme indiqué ci-dessus Depuis la ligne de 

private static final Foo INSTANCE = new Foo();

n'est exécuté que lorsque la classe FooLoader est effectivement utilisé, cela prend en charge les paresseux de l'instanciation, et il est garanti d'être thread-safe.

Est-ce correct?

  • En double stackoverflow.com/q/5842273/823393
  • Ce n'est pas vraiment l'initialisation tardive si? L'instance peut être chargé avant le getInstance méthode invoquée.
  • Ce n'est certainement paresseux. Le INSTANCE est instancié sur la référence première de la classe. Qui ne sera référencé dans la première invocation de getInstance. Mais je voudrais enlever la création de vérifier dans le constructeur.
  • dites-moi, qu'arriverait-il si je l'ai fait - Class.forName("Foo")?
  • il va créer la instace de la classe Foo. Que initialixation comprend les champs statiques et thr statique bloc. Il ne comprend pas statique classes enfant. vous pouvez essayer vous-même pour voir.
  • C'est le Titulaire du modèle.

InformationsquelleAutor tuntun fdg | 2013-04-03
  1. 20

    Votre deuxième extrait de code est, à mon avis, la meilleure façon de thread-safe paresseusement de l'initialisation d'un singleton. En fait, elle a un nom de modèle

    Initialisation sur demande du titulaire de l'idiome

    Je vous suggère de l'utiliser.

    • Merci beaucoup. passé par l'article parfait explnation
    • La réponse sur le comportement de chargement de classe de la machine plutôt que de faire votre paresse explicite me semble une mauvaise idée. Il y en a probablement pas d'avantage en termes de performances par rapport à la méthode directe.
    • J'ai vu votre exemple utilisé DCL + volatile. Si elle est correcte (wrt déclarant volatils ) je préfère utiliser son dernier exemple, puis la DCL. Je trouve que c'est plus lisible et moins verbeux. Enfin, votre exemple est mauvais, vous devriez être en synchronisation sur Foo.class et pas l'instance.
    • Je suis d'accord c'est la meilleure solution. C'est plus rapide que le double contrôle de verrouillage. Il a moins conceptuel de bagages que l'Enum Façon, et fonctionne exactement de la même manière. (Sauf getInstance est la seule méthode statique, puis utilisez les OP du premier extrait de code.)
    InformationsquelleAutor John Vint
  2. 6

    De la première conception est en fait paresseux. Pensez à ce sujet, l'instance n'est créé que lorsque la classe est initialisée; la classe n'est initialisé lors de l' getSingleton() méthode est appelée [1]. Si l'instance n'est créé que lorsque c'est demandé, c'est à dire qu'il est paresseusement créé.

    [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.1

    • +1 tu as raison c'est toujours paresseux mais j'imagine qu'il aurait d'autres méthodes disponibles dans une autre statique de référence permettrait de créer.
    • Il est peu probable qu'un singleton classe contient des méthodes statiques (autres que getInstance())
    • mais il n'est pas improbable qu'il contient un public static field 🙂
    InformationsquelleAutor ZhongYu
  3. 2

    Le second est très mauvais en termes de lisibilité, le premier est adapté. Jetez un oeil à cette l'article. Son environ le double de vérifier le verrouillage, mais également vous donner des informations à l'échelle sur les singletons de multithreading.

    • Comment est la seconde très mauvais?
    • Cela va fonctionner, mais je ne vois pas de toute utilisation dans FooLoader et si l'instruction à l'intérieur de constructeur. Le laisser être pas mal mais le surcharger. Rappelez-vous que d'autres personnes vont lire votre code. Donc garder les choses simples.
    • Je suis d'accord, avoir le chèque dans le constructeur n'est pas nécessaire et doit être supprimé. Mais quand on parle de fil-sécurité, je ne vois absolument rien de mal avec le deuxième extrait de code.
    • Dans les deux cas, une nouvelle instance est créée lors de l'initialisation de classe, donc pas de différence.
    • Ce n'est pas correct. Essayez-le vous-même. Ont le constructeur du singleton de type de classe de certains println. Ont maintenant une autre méthode statique faire une autre méthode println. Si vous étiez à droite, puis vous devriez voir les deux printlns si vous n'avez jamais invoquer la getInstance et seulement d'invoquer l'autre méthode qui fait un simple println
    InformationsquelleAutor Mikhail
  4. 1

    La meilleure façon est en fait d'utiliser le Enum Façon:

    public enum Singleton {
    INSTANCE;
    public void execute (String arg) {
            //... perform operation here ...
    }
}
    • Je dirais que c'est la pire façon... et Bloch devrait rembourser ses lecteurs:)
    • Hey, je sais: le gars est mauvais...
    • +1 zhong.j.yu, j'ai jamais trop aimé ce modèle, même si Bloch parlé si hautement et puis tout le monde a suivi ça :/
    InformationsquelleAutor Jean Logeart
  5. 0

    À mon avis, ce n'est pas approprié au modèle à utiliser. Il fait des hypothèses sur la JVM du comportement qui ne sont pas anodines et déroutant. Aussi, il a un mannequin de classe. Mannequin classes doivent être évités si possible.

    Je suggère l'approche directe:

    public class Foo {
    private volatile static final Foo instance = null;

    private Foo() {
    }

    public static Foo instance() {
        if (instance == null) instance = new Foo();
        return instance;
        }
    }
}

    ... bien que cela ne fonctionne pas comme-est - ce n'est pas thread-safe.. Ce que vous voulez vraiment est le double-vérifier le modèle présenté dans l'Article 71 de Bloch Efficace Java; voir ici. L'adaptation de l'exemple sur le lien à votre cas, nous obtenons:

    public class Foo {
    private volatile static final Foo instance = null;

    private Foo() {
    }

    public static Foo instance() {
        if (instance != null) return instance;
        synchronized(instance) {
           Foo result = instance;
           if (instance == null) {
                result = instance = new Foo();
           return result;
        }
    }
}

    Notes:

    • Ne vous inquiétez pas au sujet de la performance de ce code, moderne Jvm prendre soin d'elle et c'est très bien. Après tout, l'optimisation prématurée est la racine de tous les maux.
    • Que ce qui est suggéré dans d'autres réponses, le ci-dessus n'est pas Bloch préféré de solution, mais je pense que l'utilisation d'un enum pour un singleton est sémantiquement inapproprié, tout comme ce que l'OP n'a à l'origine.
    InformationsquelleAutor einpoklum