想象一下,有两个线程 A ,_ B 将分别在 Map 中放置两个不同的值, v1 和 v2 具有相同的密钥 . 密钥最初不在 Map 中 . 它们以这种方式交错:
线程 A 调用 containsKey 并发现密钥不存在,但会立即暂停 .
线程 B 调用 containsKey 并发现密钥不存在,并且有时间插入其值 v2 .
线程 A 继续并插入 v1 ,_ "peacefully"覆盖(因为 put 是线程安全的)线程 B 插入的值 .
现在线程 B "thinks"它已经成功插入了它自己的值 v2 ,但是 Map 包含 v1 . 这确实是一场灾难,因为线程 B 可以调用 v2.updateSomething() 并且"think"表示 Map 的消费者(例如其他线程)可以访问该对象,并且可能会看到可能重要的更新("like: this visitor IP address is trying to perform a DOS, refuse all the requests from now on") . 相反,该对象将很快被垃圾收集和丢失 .
6 回答
get()
方法是线程安全的,其他用户为您提供了有关此特定问题的有用答案 .但是,虽然
ConcurrentHashMap
是HashMap
的线程安全替代品,但重要的是要意识到如果您正在执行多个操作,则可能必须显着更改代码 . 例如,请使用以下代码:在多线程环境中,这是竞争条件 . 你必须使用ConcurrentHashMap.putIfAbsent(K key, V value)并注意返回值,它告诉你put操作是否成功 . 阅读文档了解更多详情 .
回答评论,要求澄清为什么这是竞争条件 .
想象一下,有两个线程
A
,_B
将分别在 Map 中放置两个不同的值,v1
和v2
具有相同的密钥 . 密钥最初不在 Map 中 . 它们以这种方式交错:线程
A
调用containsKey
并发现密钥不存在,但会立即暂停 .线程
B
调用containsKey
并发现密钥不存在,并且有时间插入其值v2
.线程
A
继续并插入v1
,_ "peacefully"覆盖(因为put
是线程安全的)线程B
插入的值 .现在线程
B
"thinks"它已经成功插入了它自己的值v2
,但是 Map 包含v1
. 这确实是一场灾难,因为线程B
可以调用v2.updateSomething()
并且"think"表示 Map 的消费者(例如其他线程)可以访问该对象,并且可能会看到可能重要的更新("like: this visitor IP address is trying to perform a DOS, refuse all the requests from now on") . 相反,该对象将很快被垃圾收集和丢失 .它是线程安全的 . 但是,它的线程安全方式可能不是您所期望的 . 您可以从以下方面看到一些“提示”:
要以更完整的图片了解整个故事,您需要了解
ConcurrentMap
界面 .原始
Map
提供了一些非常基本的读/更新方法 . 即使我能够进行Map
的线程安全实现;有很多情况下人们不考虑我的同步机制就无法使用我的Map . 这是一个典型的例子:这段代码不是线程安全的,即使 Map 本身也是如此 . 同时调用
containsKey()
的两个线程可能认为没有这样的密钥,因此它们都插入Map
.为了解决这个问题,我们需要明确地进行额外的同步 . 假设我的Map的线程安全性是通过同步关键字实现的,您需要这样做:
这些额外的代码需要您了解 Map 的“同步细节” . 在上面的例子中,我们需要知道同步是通过“synchronized”实现的 .
ConcurrentMap
界面更进了一步 . 它定义了一些涉及多个 Map 访问的常见"complex"动作 . 例如,上面的示例公开为putIfAbsent()
. 通过这些"complex"操作,ConcurrentMap
的用户(在大多数情况下)不需要同步具有对 Map 的多次访问的操作 . 因此,Map的实现可以执行更复杂的同步机制以获得更好的性能 .ConcurrentHashhMap
就是一个很好的例子 . 事实上,线程安全是通过为 Map 的不同分区保留单独的锁来维护的 . 它是线程安全的,因为对映射的并发访问不会破坏内部数据结构,或导致任何更新丢失意外等考虑到上述所有因素,Javadoc的含义将更加清晰:
"Retrieval operations (including get) generally do not block"因为
ConcurrentHashMap
未使用"synchronized"作为其线程安全性 .get
的逻辑本身负责线程安全性;如果你在Javadoc中进一步观察:检索非阻塞,甚至更新都可以同时发生 . 但是,非阻塞/并发更新并不意味着它是线程UNsafe . 它只是意味着它使用除了简单的“同步”之外的一些方法来实现线程安全 .
但是,由于未公开内部同步机制,如果要执行
ConcurrentMap
提供的其他复杂操作,则可能需要考虑更改逻辑,或者考虑不使用ConcurrentHashMap
. 例如:从某种意义上说,
ConcurrentHashmap.get()
是线程安全的它不会抛出任何异常,包括
ConcurrentModificationException
它将返回在过去的某个(最近)时间为真的结果 . 这意味着两次背靠背调用get可以返回不同的结果 . 当然,这也适用于任何其他
Map
.HashMap
基于hashCode
分为"buckets" .ConcurrentHashMap
使用了这个事实 . 它的同步机制基于阻塞桶而不是整个Map
. 这样,很少有线程可以同时写入几个不同的桶(一个线程可以一次写入一个桶) .从
ConcurrentHashMap
读取几乎不使用同步机制 . 我说几乎是因为它会在获得null
值时使用同步 . 基于ConcurrentHashMap
无法存储null
值的事实(是的,除了键值也不能为空)如果它将获得该值,则必须表示在写入键值对的过程中调用了读取(在输入之后)是为密钥创建的,但它的值尚未设置 - 它是null
) . 在这种情况下,读取线程需要等到写入完成 .因此
read()
的结果将基于当前的 Map 状态 . 如果您读取了更新过程中的键值,则可能会因为写入过程尚未完成而获得旧值 .它只是意味着当一个线程正在更新并且一个线程正在读取时,无法保证首先及时调用ConcurrentHashMap方法的线程将首先执行其操作 .
考虑项目的更新,告诉鲍勃在哪里 . 如果一个线程询问Bob所处的位置,而另一个线程在更新时说他来到“内部”,则无法预测读者线程是否会将Bob的状态设置为“内部”或“外部” . 即使更新线程首先调用该方法,读取器线程也可能会获得“外部”状态 .
线程不会引起彼此的问题 . 代码是ThreadSafe .
一个线程不会进入无限循环或开始生成奇怪的NullPointerExceptions,或者使用旧状态的一半和新的一半获得“itside” .
当
put()
方法更新CHM时,它会将该键的值设置为null,然后创建一个新条目并更新CHM .get()
方法使用此空值作为另一个线程使用相同密钥更新CHM的信号 .