singleton avec volatile en Java

class MyClass
{
      private static volatile Resource resource;

      public static Resource getInstance()
      {
            if(resource == null)
                  resource = new Resource();
            return resource;
      }
 }

Ici mon doute est selon la java de la simultanéité dans la pratique si vous utilisez volatile, coffre-fort à la publication qui se passe (c'est à dire dès que la référence est visible à un autre thread de données est également disponible). Donc, puis-je l'utiliser ici? Mais si elle est correcte, alors supposons que thread1 vérifie maintenant les "ressources" et c'est null si il commence la création de l'objet. Alors que thread1 est la création de l'objet, un autre thread, c'est à dire thread2 vient et de vérifier la valeur de la "ressource" et thread2 trouve nulle (on suppose la création de la "ressource" de l'objet prend un peu de temps considérable et que thread1 n'a pas encore achevé la création pour la sécurité de la publication n'est pas arrivé donc inaccessible thread2 )puis il va également commencer la création de l'objet? si oui, alors la classe de l'invariant de pauses. Suis-je la corriger? Merci de m'aider dans la compréhension de ce surtout l'utilisation de la volatilité ici.

source d'informationauteur Trying

concurrency java

13

volatils résout un problème qui est visibilité . Si vous écrivez à une seule variable qui est déclarée volatils alors la valeur sera visible par les autres thread immédiatement. Comme nous le savons tous, nous avons différents niveaux de cache en os L1, L2, L3 et si nous écrire à une variable dans un thread, il n'est pas garanti d'être visible pour les autres, donc si l'on utilise volatile, il écrit direct à la mémoire et est visible pour les autres. Mais instable ne permet pas de résoudre la question de la atomicité c'est à dire int a; a++; n'est pas sûr. COMME il y a trois instructions machine associée.

Vous avez raison, plusieurs threads peuvent essayer de créer un objet de la Ressource. Volatile seulement garantit que si un thread mises à jour de la référence, toutes les autres threads de voir la nouvelle référence, et non de mise en cache de référence. C'est plus lent, mais plus sûr.

Si vous n'avez besoin que d'une seule ressource qui n'est pas chargé, vous avez besoin de faire quelque chose comme ceci:

class MyClass
{
      private static volatile Resource resource;
      private static final Object LOCK = new Object();

      public static Resource getInstance()
      {
            if(resource == null) { 
                synchronized(LOCK) { //Add a synch block
                    if(resource == null) { //verify some other synch block didn't
                                           //write a resource yet...
                        resource = new Resource();
                    }
                }
            }
            return resource;
      }
 }

7

Je sais que vous ne vous posez pas de meilleures solutions, mais c'est certainement la peine si vous êtes à la recherche pour un paresseux singleton solution.

Utiliser une private static de la classe à charger le singleton. La classe n'est pas chargé jusqu'à ce que l'invocation et donc la référence n'est pas chargé jusqu'à ce que la classe est. Chargement de classe par la mise en œuvre est thread-safe et vous aussi vous engager très peu de frais généraux (dans le cas où vous faites répétitif volatile des charges [qui peut toujours être bon marché], cette résolution toujours aux charges normales après la construction initiale).
```
class MyClass {
    public static Resource getInstance() {
        return ResourceLoader.RESOURCE;
    }

    private static final class ResourceLoader {
        private static final Resource RESOURCE = new Resource();
    }
}
```
1

Je pense que vous devriez utiliser syncronized mot-clé avant de getInstance définition.

Pour de meilleures performances, vous pouvez utiliser vérifié en Double verrouillage modèle:
- Double-vérifier le verrouillage et le pattern Singleton sur IBM
- Double-vérifier le verrouillage sur le Wiki
0

Lorsqu'il est appliqué à un champ, la Java volatils garantit que:
1. (Dans toutes les versions de Java) Il y a un mondial de la commande sur le lit
  et écrit dans un contexte de volatilité variable. Cela implique que chaque thread
  l'accès à un champ volatile va lire sa valeur actuelle avant
  en continuant, au lieu de (potentiellement) à l'aide d'une valeur mise en cache. (Cependant,
  il n'y a aucune garantie sur l'ordre relatif de la volatilité des lectures
  et écrit régulièrement des lectures et écritures, ce qui signifie que c'est
  généralement pas utile d'enfilage de construire.)
2. (En Java 5 ou version ultérieure) Volatile lit et écrit d'établir un
  -passe-avant la relation, à l'instar de l'acquisition et de la libération d'un
  mutex.
Plus info.
0

Vous avez raison, dans ce cas, la Ressource peut être construit à deux reprises en raison de la race que vous décrivez. Si vous souhaitez implémenter un singleton (sans verrouillage explicite) dans Java 5+, utiliser un enum singleton comme décrit dans les réponses à la Ce qui est un moyen efficace de mettre en œuvre un pattern singleton en Java?.
0

volatile mot-clé garantit que lire et à écrire à cette variable sont atomiques.

Selon la tutoriel
```
Reads and writes are atomic for all variables declared volatile
```
À l'aide de variables réduit le risque de consistance de la mémoire
des erreurs, car tout écrire dans une variable volatile établit un
-passe-avant la relation avec les lectures suivantes de la même
variable. Cela signifie que la modification d'une variable volatile sont toujours
visible par les autres threads. Qui plus est, cela signifie aussi que quand un
thread lit une variable volatile, il ne voit pas seulement les changements les plus récents
de la volatilité, mais aussi les effets secondaires du code qui a conduit
la modification.
0

tout d'abord, avoir un Singleton de cette façon, vous êtes essentiellement la création d'un objet global qui est une mauvaise pratique. Je pense que vous utiliser les Énumérations à la place.

Voici ma suggestion pour ajouter volatils & concert.

Remarque: nous avons encore à faire vérifier.

public class MySingleton {
    private static volatile MySingleton instance;
    private MySingleton() {}

    synchronized private static void newInstance() {
        if(instance == null) {
            instance = new MySingleton();
        }
    }

    public static MySingleton get() {
        if(instance == null) {
            newInstance();
        }
        return instance;
    }
}

Vous devez vous connecter pour publier un commentaire.