ConcurrentHashMap
文档说:
检索操作(包括 get)通常不会阻塞,因此可能与更新操作(包括 put 和 remove)重叠。检索反映了最近完成的更新操作在其开始时的结果。 (更正式地说,给定键的更新操作与报告更新值的该键的任何(非空)检索具有发生之前关系。)
但我无法理解检索操作如何不会因同一密钥的更新/删除操作而阻塞?
“给定键的更新操作与该键的任何(非空)检索具有先发生关系”
这表明并发哈希映射有某种方式为同一键上的读取/更新/删除操作创建序列。但这意味着读取操作会被更新/删除操作阻止。
不知道我在这里缺少什么。
但我无法理解检索操作如何不会因同一密钥的更新/删除操作而阻塞?
首先,它“如何”实现是一个实现细节。如果你真的想/需要了解“如何”,你需要查看源代码。它可以从不同的地方获得。
但这实际上想说的是:
-
get
不阻塞,并且
- 当你做某事时你会看到什么
get
是来自的值最近完全的 put
手术对于那把钥匙。
所以如果你做一个get
而一个put
正在进行中,您可能会看到之前的值put
.
请注意,第二个要点解释了(隐含)why有可能get
是非阻塞的。没有必要get(42)
等待一个put(42, value)
目前正在进行中......自get
允许调用返回先前的值。
TL;DR - 无需阻止。
那些关于“发生在之前“关系将其与 Java 内存模型的语义联系起来。如果您正在对代码进行深入分析,这可能很重要。但是对于浅层理解什么ConcurrentHashMap
确实如此,你可以忽略它。
...这表明并发哈希映射有某种方式为同一键上的读取/更新/删除操作创建序列。
这根本不意味着这一点。但要理解您引用的语句的真正含义,您需要对 Java 内存模型有很好的理解。我认为在 StackOverflow 问答中向您传达这一点是不可行的。我建议你拿几个hours阅读并理解 JMM ...通过阅读 JLS。然后,再做一次。
这不是凭直觉理解就足够的事情。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)