Est ConcurrentHashMap.get() de la garantie de voir un précédent ConcurrentHashMap.put() par thread différent?

Quelques bonnes réponses ici, mais autant que je sache, personne n'a effectivement fourni une réponse canonique à la question posée: "Est ConcurrentHashMap.get() de la garantie de voir un précédent ConcurrentHashMap.put() par thread différent". Ceux qui ont dit oui n'ont pas fourni une source.

Donc: oui, c'est garanti. Source (voir la section "Mémoire de la Cohérence Propriétés"):

Actions dans un thread avant de placer un objet dans une collecte simultanée arriver-avant que les actions mises en place suite à l'accès ou de suppression de cet élément de la collection dans un autre thread.

OriginalL'auteur Cowan

Une chose à considérer est de savoir si vos clés sont égaux et ont les mêmes hashcodes à deux reprises de "get" appel. Si ils sont juste Strings alors oui, il ne va pas être un problème ici. Mais comme vous n'avez pas donné le type générique de la clés, et vous avez ramené "sans importance" détails dans le pseudo-code, je me demande si vous utilisez une autre classe comme une clé.

Dans tous les cas, vous pouvez en outre journal le hashcode de clés utilisées pour les gets/les met dans les fils 1 et 2. Si ces derniers sont différents, vous avez votre problème. Notez également que key1.equals(key2) doit être vrai; ce n'est pas quelque chose que vous pouvez vous connecter de façon définitive, mais si les touches ne sont pas définitive des classes, il serait utile de consignation de leur nom de classe entièrement qualifié, puis, regardant la méthode equals() pour la classe ou les classes pour voir si il est possible que la deuxième clé pourrait être considérée comme inégale à la première.

Et pour répondre à votre titre - oui, ConcurrentHashMap.get() est garanti de voir sur la précédente put(), où les "anciens", il y a une se passe-avant relation entre les deux, comme spécifié par le Modèle Mémoire Java. (Pour le ConcurrentHashMap en particulier, c'est essentiellement ce que vous attendez, avec la mise en garde que vous ne pouvez pas être en mesure de dire qui se passe d'abord si les deux threads s'exécutent à "exactement de la même temps" sur les différents cœurs. Dans votre cas, cependant, vous devriez certainement voir le résultat de la mettre() dans le thread 2).

OriginalL'auteur Andrzej Doyle

Je ne pense pas que le problème est dans le "ConcurrentHashMap", mais plutôt quelque part dans votre code ou sur le raisonnement à propos de votre code. Je ne peux pas place à l'erreur dans le code ci-dessus (peut-être que nous n'avons tout simplement pas voir le mauvais?).

Mais pour répondre à votre question "Est ConcurrentHashMap.get() de la garantie de voir un précédent ConcurrentHashMap.put() par thread différent?" J'ai bidouillé un petit programme de test.

En bref: Non, ConcurrentHashMap est OK!

Si la carte est mal écrit le programme suivant shoukd impression de "Mauvais accès à!" au moins de temps en temps. Il jette à 100 Threads avec 100000 appels à la méthode décrite ci-dessus. Mais il imprime "Tout est ok!".

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
public class Test {
private final static ConcurrentHashMap<String, Test> map = new ConcurrentHashMap<String, Test>();
private final static Semaphore lock = new Semaphore(1);
private static int counter = 0;
public static void main(String[] args) throws InterruptedException {
ExecutorService pool = Executors.newFixedThreadPool(100);
List<Callable<Boolean>> testCalls = new ArrayList<Callable<Boolean>>();
for (int n = 0; n < 100000; n++)
testCalls.add(new Callable<Boolean>() {
@Override
public Boolean call() throws Exception {
doSomething(lock);
return true;
}
});
pool.invokeAll(testCalls);
pool.shutdown();
pool.awaitTermination(5, TimeUnit.SECONDS);
System.out.println("All ok!");
}
static void doSomething(Semaphore lock) throws InterruptedException {
boolean haveLock = lock.tryAcquire(3000, TimeUnit.MILLISECONDS);
if (haveLock) {
Test foo = map.get("key");
if (foo == null) {
foo = new Test();
map.put("key", new Test());
if (counter > 0)
System.err.println("Bad access!");
counter++;
}
lock.release();
} else {
System.err.println("Fail to lock!");
}
}
}

OriginalL'auteur Arne Deutsch

Assistons-nous à une intéressante manifestation de la Java du Modèle de Mémoire? Dans quelles conditions sont les registres vidé la mémoire principale? Je pense que c'est garanti que si deux threads synchroniser sur le même objet, puis ils vont voir un uniforme de la mémoire de vue.

Je ne sais pas ce Semphore n'en interne, il doit évidemment faire quelques synchroniser, mais savons-nous?

Ce qui se passe si vous ne

synchronize(dedicatedLockObject)

au lieu de l'acquisition de la sémaphore?

OriginalL'auteur djna