ConcurrentHashMap 文档说:
Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset. (More formally, an update operation for a given key bears a happens-before relation with any (non-null) retrieval for that key reporting the updated value.)
但我无法理解检索操作如何不阻塞同一键的更新/删除操作？
“给定键的更新操作与该键的任何(非空)检索具有发生前关系”
这表明并发 HashMap 有某种方式为同一键上的读取/更新/删除操作创建序列。但这意味着读取操作会被更新/删除操作阻止。
不确定我在这里遗漏了什么。
最佳答案
But I am not able to understand how retrieval operation do not block with update/remove operation for same key ?
首先，它“如何”执行是一个实现细节。如果你真的想/需要了解“如何”，你需要查看源代码。它可以从不同的地方获得。
但这实际上是在说:
get不阻塞，并且- 当您执行
get时，您看到的是最近完成put操作 的值那把 key 。
因此，如果您在执行 put 时执行 get，您可能会看到上一个 put 的值。
请注意，第二个要点解释了(隐含地)为什么 get 可能是非阻塞的。 get(42) 无需等待当前正在进行的 put(42, value) 完成……因为 get 允许调用返回以前的值。
TL;DR - 无需阻止。
关于“发生在”关系的内容与 Java 内存模型的语义有关。如果您正在对代码进行深入分析，这可能很重要。但是为了浅层了解ConcurrentHashMap的作用，可以忽略它。
... that sort of indicate that concurrent hash map has some way create sequence for read/update/remove operations on same key.
这根本不是暗示。但是要理解您引用的语句的真正含义，您需要对 Java 内存模型有很好的理解。而且我认为在 StackOverflow 问答中向您传达这一点是不可行的。我建议您花几个小时阅读和理解 JMM ... 通过阅读 JLS。然后，再做一次。
这不是凭直觉理解就足够的东西。
关于Java并发hashMap检索，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51219103/