java - ConcurrentHashMap的get为什么可以不加锁?

Answer 1

1. L'implémentation interne utilise des verrous, vous n'avez donc pas besoin d'ajouter une autre couche de verrous lorsque vous l'utilisez

       『他都是复制出一个新的数组进行复制, 而非在原地操作』 你在哪里看到有复制的代码？

   2/3. Si vous lisez alors que l'écriture n'est pas terminée, vous lirez null À ce moment, le verrou est verrouillé par l'opération d'écriture, puis relisez.

Answer 2

1. get Pas besoin de verrouiller, la simple lecture ne modifiera pas les données

2. readValueUnderLock Les conditions normales ne seront pas exécutées

3. e.value ne sera pas utilisé pour null L'auteur Doug Lea explique ainsi

Not quite. You are right that it should never be called. However, the JLS/JMM can be read as not absolutely forbidding it from being called because of weaknesses in required ordering relationships among finals vs volatiles set in constructors (key is final, value is volatile), wrt the reads by threads using the entry objects. (In JMM-ese, ordering constraints for finals fall outside of the synchronizes-with relation.) That's the issue the doc comment (pasted below) refers to. No one has ever thought of any practical loophole that a processor/compiler might find to produce a null value read, and it may be provable that none exist (and perhaps someday a JLS/JMM revision will fill in gaps to clarify this), but Bill Pugh once suggested we put this in anyway just for the sake of being conservatively pedantically correct. In retrospect, I'm not so sure this was a good idea, since it leads people to come up with exotic theories.

Dans la version supérieure de jdk, ConncurrentHashMap a été complètement réécrit et cette partie du code a disparu.

Answer 3

ConncurrentHashMap a été introduit par jdk5. Son propre fonctionnement garantit la sécurité des threads, il n'est donc pas nécessaire de le verrouiller

.

Answer 4

Modèle classique de lecture et d'écriture, généralement aucun verrouillage n'est requis pour la lecture

Answer 5

L'opération Get ne modifie pas le tableau sous-jacent ou la liste chaînée. La question de l'auteur d'origine peut être qu'un autre fil de discussion est mis en même temps pendant Get, ou qu'un autre fil de discussion est supprimé en même temps pendant Get. En fait, il n'y a pas de problème ici. Si get est devant et put est à l'arrière, alors vous obtiendrez null. Si Remove est devant après get, vous obtiendrez également null. Il n'y aura aucune situation où vous obtiendrez null si vous le mettez en premier, ou obtiendrez obj si vous le supprimez en premier. Parce que l'opération finale de suppression ou de mise est le paramètre atomique segment[i].table[j]. L'opération get n'a aucune chance de perturber cette opération