Comment éviter la surcharge de performances liée à l'utilisation d'un modèle volatile dans un singleton?

Si vous voulez éviter d'utiliser volatile, alors vous pouvez initialiser lors du chargement de la classe et utiliser un constructeur privé pour éviter de créer une nouvelle instance.

public class Singleton{
    //Initialized when class loading
    private static final Singleton INSTANCE = new Singleton();

    //To avoid creating new instance of Singleton
    private Singleton(){}

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

Vous pouvez utiliser Initialisation différée avec la classe statique Holder

class Singleton 
{ 

    private Singleton() {} 

    private static class LazyLoader{ 
        static final Singleton obj = new Singleton();
    }

    public static Singleton getInstance() 
    { 
        return LazyLoader.obj;
    } 
} 

La chose importante à noter ici est que le constructeur doit être sûr, sinon le chargeur de classe lancera NoClassDefFoundError

Vous devez utiliser Enums pour l'implémentation de Singleton.

Joshua Bloch suggère d'utiliser Enum pour implémenter le modèle de conception Singleton car Java garantira que toute valeur enum n'est instanciée qu'une seule fois dans un Java programme. L'inconvénient est que le type enum est quelque peu inflexible; pour exemple, il n'autorise pas l'initialisation tardive.

public class EnumDemo {
    public static void main(String[] args) {
        EnumSingleton singleton = EnumSingleton.INSTANCE;
        System.out.println(singleton.getValue());
        singleton.setValue(2);
        System.out.println(singleton.getValue());
    }
}

public enum EnumSingleton {
    INSTANCE;
    int value;
    public int getValue() {
        return value;
    }
    public void setValue(int value) {
        this.value = value;
    }
}

Cet article de a joliment énuméré d'autres avantages de l'utilisation d'Enums: Instanciation java singleton

Vous ne comprenez pas vraiment ce que fait volatile , mais pour être juste, Internet et le stackoverflow, y compris, sont simplement pollués par des réponses erronées ou incomplètes à ce sujet. J'avoue aussi que je pense que j'ai une bonne idée de ce sujet, mais que je dois parfois relire certaines choses.

Ce que vous avez montré ici - s'appelle l'idiome "double contrôle de verrouillage" et c'est un cas d'utilisation parfaitement valide pour créer un singleton. La question est de savoir si vous en avez vraiment besoin dans votre cas (l'autre réponse a montré une manière beaucoup plus simple, ou vous pouvez également lire le "enum singleton pattern" si vous le souhaitez). C'est un peu drôle de voir combien de personnes savent que volatile est nécessaire pour cet idiome, mais ne peuvent pas vraiment dire pourquoi cela est nécessaire.

DCL est faire principalement deux choses - assure l ' atomicité (plusieurs threads ne peuvent pas entrer dans le bloc synchronisé en même temps) et garantit qu'une fois créé, tous les threads verront cette instance créée, appelée visibilité . En même temps, cela garantit que le bloc synchronisé sera entré une seule fois , tous les threads suivants n'auront pas besoin de le faire.

Vous auriez pu le faire facilement via :

 public Singleton get() {
    if (instance == null) {
        synchronized (this) {
            if (instance == null) {
                Singleton copy = new Singleton();
                copy.setSome(new Object());
                instance = copy;
            }
        }
    }
    return instance; 
}

Mais maintenant, chaque thread qui a besoin de cette instance doit entrer en compétition pour le verrou et doit entrer dans ce bloc synchronisé.

Certaines personnes pensent que: "hé, je peux contourner ça!" et écrivez (entrez donc le bloc synchronisé seulement une fois):

private Singleton instance;

public Singleton get() {
    if (instance == null) {  
        synchronized (this) {
            if (instance == null) { 
                instance = new Singleton();
                instance.setSome(new Object());
            }
        }
    }
    return instance; 
}

Aussi simple que cela soit - c'est cassé . Et ce n'est pas facile à expliquer.

• il est cassé car il y a deux lectures indépendantes de instance ; JMM permet de les commander à nouveau; il est donc entièrement valide que if (instance == null) ne voit pas de null; tandis que return instance; voit et renvoie un null . Oui, c'est contre-intuitif, mais tout à fait valide et prouvable (je peux écrire un test jcstress pour le prouver en 15 minutes).

• le deuxième point est un peu plus délicat. Supposons que votre singleton ait un champ que vous devez définir.

Regardez cet exemple:

static class Singleton {

    private Object some;

    public Object getSome() {
        return some;
    }

    public void setSome(Object some) {
        this.some = some;
    }
}

Et vous écrivez un code comme celui-ci pour fournir ce singleton:

  private Singleton instance; // no volatile

  public Singleton get() {
    if (instance == null) {  
      synchronized (this) {
        if (instance == null) { 
          instance = new Singleton();
        }
      }
    }
    return instance; 
  }

Puisque l ' écriture dans le volatile ( instance = new Singleton (); ) se produit avant le réglage champ dont vous avez besoin instance.setSome (new Object ()); ; un thread qui lit cette instance peut voir que instance n'est pas null, mais lors de l'exécution de instance.getSome () , il verra un null. La bonne façon de procéder serait (en plus de rendre l'instance volatile):

  private Singleton instance;

  public Singleton get() {
    synchronized (this) {
      if (instance == null) {
        instance = new Singleton();
      }
      return instance;
    }
  }

Ainsi volatile ici est nécessaire pour publication sécurisée ; afin que la référence publiée soit "en toute sécurité" vue par tous les threads - tous ses champs sont initialisés. Il existe d'autres moyens de publier en toute sécurité une référence, comme final défini dans le constructeur, etc.

Fait de la vie: les lectures sont moins chères que les écritures ; vous ne devriez pas vous soucier de ce que les lectures volatiles font sous le capot tant que votre code est correct; alors ne vous inquiétez pas des "lectures depuis la mémoire principale" (ou mieux encore, n'utilisez pas cette phrase sans même la comprendre partiellement).