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

Une bonne ressource pour comprendre pourquoi volatile est nécessaire provient de la JCIP livre. Wikipedia a un explication satisfaisante de ce matériel également.

Le vrai problème est que Thread A peut attribuer un espace mémoire pour instance avant d'avoir fini de construire instance . Thread B verra cette affectation et essaiera de l'utiliser. Il en résulte que Thread B échoue parce qu'elle utilise une version partiellement construite de instance .

Answer 2

Comme cité par @irreputable, le volatile n'est pas cher. Même si elle est chère, la cohérence doit être privilégiée par rapport aux performances.

Il existe une autre méthode propre et élégante pour les singletons paresseux.

public final class Singleton {
    private Singleton() {}
    public static Singleton getInstance() {
        return LazyHolder.INSTANCE;
    }
    private static class LazyHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

Article source : Initialisation sur demande du titulaire_idiom de wikipedia

En génie logiciel, l'idiome du titulaire de l'initialisation à la demande (design pattern) est un singleton chargé paresseusement. Dans toutes les versions de Java, cet idiome permet une initialisation paresseuse sûre, hautement concurrente et performante.

Puisque la classe n'a pas de static à initialiser, l'initialisation se termine trivialement.

La définition de la classe statique LazyHolder à l'intérieur de celui-ci n'est pas initialisé jusqu'à ce que la JVM détermine que LazyHolder doit être exécuté.

La classe statique LazyHolder n'est exécutée que lorsque la méthode statique getInstance est invoquée sur la classe Singleton, et la première fois que cela se produit, la JVM va charger et initialiser la classe LazyHolder classe.

Cette solution est à l'abri des threads sans nécessiter de constructions spéciales du langage (c'est-à-dire volatile o synchronized ).

Answer 3

Il n'y a pas de verrouillage doublement vérifié pour les performances. C'est un brisé modèle.

Laisser les émotions de côté, volatile est ici parce que sans lui, au moment où le second fil passe instance == null le premier fil pourrait ne pas être construit new Singleton() encore : personne ne promet que la création de l'objet se passe avant affectation à instance pour tout autre thread que celui qui crée réellement l'objet.

volatile établit à son tour se passe avant entre les lectures et les écritures, et corrige le modèle cassé.

Si vous recherchez la performance, utilisez plutôt la classe statique interne du titulaire.

Answer 4

Regardez :

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Et

http://en.wikipedia.org/wiki/Double-checked_locking

(plus précisément le deuxième, au milieu de la page). Il contient un exemple qui est le portrait craché de ce que vous avez posté et l'explique.

Answer 5

Si vous ne l'aviez pas, un deuxième thread pourrait entrer dans le bloc synchronisé après que le premier l'ait mis à null, et votre cache local penserait toujours qu'il est null.

La première n'a pas pour but d'être correcte (si c'était le cas, vous avez raison de dire que cela irait à l'encontre du but recherché) mais plutôt d'être optimisée.