Java并发hashMap检索 [英] Java concurrent hashMap retrieval

问题描述

ConcurrentHashMap 文档说:

检索操作(包括get)一般不会阻塞，所以可能与更新操作(包括put和remove)重叠.检索反映了最近完成的更新操作的结果.(更正式地说，给定键的更新操作与报告更新值的该键的任何(非空)检索具有先发生关系.)

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.)

但我无法理解检索操作如何不会因相同密钥的更新/删除操作而阻塞?

But I am not able to understand how retrieval operation do not block with update/remove operation for same key ?

对给定键的更新操作与对该键的任何(非空)检索具有先发生的关系"

"an update operation for a given key bears a happens-before relation with any (non-null) retrieval for that key"

那种表明并发散列映射有某种方式为同一键上的读取/更新/删除操作创建序列.但这意味着读取操作会被更新/删除操作阻止.

that sort of indicate that concurrent hash map has some way create sequence for read/update/remove operations on same key. But that mean read operations are blocked by update/remove operations.

不确定我在这里遗漏了什么.

Not sure what I am missing here.

推荐答案

但我无法理解检索操作如何不会因相同密钥的更新/删除操作而阻塞?

But I am not able to understand how retrieval operation do not block with update/remove operation for same key ?

首先，怎么做"是一个实现细节.如果您真的想/需要了解如何"，则需要查看源代码.它可以从各个地方获得.

First of all, "how" it does it is an implementation detail. If you really want / need to understand "how", you need to look at the source code. It is available from various places.

但这实际上是在说:

• get 不会阻塞，并且
• 您在执行 get 时看到的是 最近完成 put 操作 的值那把钥匙.

• get doesn't block, and
• what you see when you do a get is the value from the most recently completed put operation for that key.

因此，如果您在 put 正在进行时执行 get，您可能会看到前一个 put 的值.

So if you do a get while a put is in progress, you may see the value from the previous put.

请注意，第二个要点解释了(隐含地)为什么 get 可能是非阻塞的.get(42) 不需要等待当前正在进行的 put(42, value) 完成......因为 get 调用允许返回前一个值.

Note that the 2nd bullet point explains (implicitly) why it is possible for get to be non-blocking. There is no need for get(42) to wait for a put(42, value) that is currently in progress to finish ... since the get call is allowed to return the previous value.

TL;DR - 无需阻止.

TL;DR - there is no need to block.

关于发生在之前"关系的内容将其与 Java 内存模型的语义联系起来.如果您正在对代码进行深入分析，这可能很重要.但是对于 ConcurrentHashMap 的作用的浅显理解，你可以忽略它.

The stuff about "happens before" relationships is relating this to the semantics of the Java Memory Model. This may be important if you are doing a deep analysis of your code. But for a shallow understanding of what ConcurrentHashMap does, you can ignore it.

...这表明并发散列映射有某种方式为同一键上的读取/更新/删除操作创建序列.

... 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.然后，再做一次.

It doesn't imply that at all. But to understand what the statement you quoted really means, you need a need a good understanding of the Java Memory Model. And I don't think it is feasible to convey that to you in a StackOverflow Q&A. I recommend you take a few hours to read and understand the JMM ... by reading the JLS. Then, do it again.

这不是直觉理解就足够的东西.

This is NOT stuff where an intuitive understanding is sufficient.

这篇关于Java并发hashMap检索的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！