Can Semaphore peut-il utiliser l'idiome de verrouillage à double vérification en toute sécurité?

Question

Est-ce que le Thead Safe suivant est java?

public class TestDCL{ 
    private static final Semaphore lock = new Semaphore(1); 
    private Object instance; 

    public Object m(){ 
     if(instance == null){ 
      lock.acquire(); 
      if(instance == null){ 
       instance = new Object(); 
      } 
      lock.release(); 
     } 
     return instance; 
    } 
} 

Answer 1

La réponse est, cela dépend. Est-ce que votre instance est modifiable ou immuable? Si instance contient un état modifiable, vous devez le déclarer volatile. La raison pour laquelle vous devez cela n'a rien à voir avec les objets partiellement construits comme le suggère @Vijay Mathew, mais plutôt avec la visibilité du fil. Les modifications apportées à l'état de votre instance singleton dans un thread ne seront pas nécessairement visibles par un autre thread. L'utilisation du mot clé volatile garantit que le matériel utilisera un mécanisme pour vider le cache afin d'éliminer les données obsolètes.

La simultanéité Java en pratique, chapitre 16.2.3, décrit les idiomes d'initialisation sécurisés et contient un idiome d'initialisation paresseux. 16.2.4 traite de l'idiome de verrouillage par double vérification.

Answer 2

Ce thread n'est pas sécurisé. L'instruction new Object(); n'est pas une opération atomique. instance cesse d'être null lorsque la mémoire lui est allouée. Un nouveau thread qui arrive à la première condition if après que la mémoire est allouée pour instance, mais avant que son constructeur est appelé renverra un objet partiellement construit. Si vous essayez d'implémenter un singleton thread-safe, utilisez Bill Pugh's solution qui est à la fois thread-safe et paresseux.

Answer 3

D'accord avec les messages précédents de Tim. Volatile fait de la visibilité et la raison pour laquelle le double contrôle de vérification a été décrit comme clever but broken concerne des objets partiellement construits (cohérence de cache/optimisations JVM). Tout est dans le livre de Goetz comme le suggère Tim, mais je voulais soulever un point autour de l'initialisation paresseuse. Pourquoi le faire? Dans mon expérience, ce n'est généralement pas nécessaire et vous vous trouvez dans un contexte multithread et vous êtes vraiment préoccupé par la sécurité de l'intialisation - vous avez introduit beaucoup de variabilité et de complexité qui est vraiment difficile à tester.

Je voudrais également souligner l'ancien avertissement de ne pas optimiser tôt. Savez-vous que la synchronisation grossière ralentit l'application? Habituellement, c'est la contention des verrous qui est lente, pas le mot-clé syncrhonization per-sa. Un test rapide avec syncrhonized et DCL confirmerait.