Pourquoi le volatile est utilisé dans le verrouillage à double vérification

Question

De La tête d'abord design patterns book, le modèle singleton avec un verrouillage doublement vérifié a été implémenté comme ci-dessous :

public class Singleton {
    private volatile static Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Je ne comprends pas pourquoi volatile est utilisé. N'est pas volatile va à l'encontre de l'objectif de l'utilisation d'un verrouillage à double vérification, à savoir la performance ?

Answer 1

En déclarant la variable comme volatile garantit que tous les accès à celui-ci lisent effectivement sa valeur actuelle en mémoire.

Sans volatile En effet, le compilateur peut optimiser les accès à la mémoire de la variable (par exemple en conservant sa valeur dans un registre), de sorte que seule la première utilisation de la variable lit l'emplacement mémoire réel contenant la variable. Cela pose un problème si la variable est modifiée par un autre thread entre le premier et le second accès ; le premier thread ne dispose que d'une copie de la première valeur (pré-modifiée), de sorte que le second thread ne peut pas lire la variable. if teste une copie périmée de la valeur de la variable.

Answer 2

Une lecture volatile n'est pas vraiment coûteuse en soi.

Vous pouvez concevoir un test pour appeler getInstance() dans une boucle serrée, pour observer l'impact d'une lecture volatile ; cependant, ce test n'est pas réaliste ; dans une telle situation, le programmeur appelle généralement getInstance() une fois et mettre en cache l'instance pour la durée de l'utilisation.

Une autre solution consiste à utiliser un final (voir wikipedia). Cela nécessite une lecture supplémentaire, qui peut devenir plus coûteuse que l'option volatile version. Le site final peut être plus rapide dans une boucle serrée, mais ce test est discutable, comme cela a été dit précédemment.

Answer 3

Je ne suis pas sûr que le volatile va régler tous les problèmes... Voir http://www.ibm.com/developerworks/java/library/j-dcl/index.html

Answer 4

Le verrouillage doublement vérifié est une technique permettant d'éviter la création d'une autre instance de singleton lors d'un appel à la fonction getInstance est réalisée dans un environnement multithreading.

Soyez attentif

• L'instance singleton est vérifiée deux fois avant l'initialisation.
• La section critique synchronisée n'est utilisée qu'après avoir vérifié l'instance singleton afin d'améliorer les performances.
• volatile sur la déclaration du membre d'instance. Cela indique au compilateur de toujours lire et écrire dans la mémoire principale et non dans le cache du CPU. Avec volatile garantissant la relation happens-before, toutes les écritures se produiront avant toute lecture de la variable d'instance.

Inconvénients

• Puisqu'elle nécessite le volatile pour fonctionner correctement, il n'est pas compatible avec Java 1.4 et les versions inférieures. Le problème est qu'une écriture non ordonnée peut permettre à la référence d'instance d'être retournée avant que le constructeur du singleton ne soit exécuté.
• Problème de performance à cause du déclin du cache pour les variables volatiles.
• L'instance singleton est vérifiée deux fois avant l'initialisation.
• C'est assez verbeux et cela rend le code difficile à lire.

Il existe plusieurs réalisations du modèle singleton, chacune ayant des avantages et des inconvénients.

• Eager loading singleton
• Verrouillage singleton doublement vérifié
• Idée de support d'initialisation à la demande
• Le singleton basé sur l'enum

La description détaillée de chacun d'entre eux est trop verbeuse, je me contente donc de mettre un lien vers un bon article Tout ce que vous voulez savoir sur Singleton