问题标签 [concurrenthashmap]

在用于ConcurrentHashMap的javadoc 中如下：

检索操作（包括 get）一般不会阻塞，因此可能与更新操作（包括 put 和 remove）重叠。检索反映了最近完成的更新操作在其开始时保持的结果。对于 putAll 和 clear 等聚合操作，并发检索可能仅反映插入或删除某些条目。类似地，迭代器和枚举返回反映哈希表在创建迭代器/枚举时或之后的某个时间点的状态的元素。它们不会抛出 ConcurrentModificationException。但是，迭代器被设计为一次只能由一个线程使用。

这是什么意思？如果我尝试同时使用两个线程迭代映射会发生什么？如果我在迭代时从映射中放置或删除一个值会发生什么？

我一直在研究编写并发Multimap的问题，并且我有一个由Google Guava AbstractSetMultimap 和 MapMaker 计算地图支持的实现，它可以按需创建值集合作为 ConcurrentHashMap 上的集合视图。通过对视图集合和各种包装器的一些关注，我认为这非常接近。

其他尝试过这个的人已经讨论过的大问题似乎是当它们为空时从底层映射中删除值集合，而不引入竞争条件。

似乎存在几个选项。

• 将空集合留在那里。这会泄漏一些 CHM，但我相信它至少是正确的。
• 尝试乐观地在空时删除集合，并在其中出现任何其他内容时进行补偿。这充满了种族，似乎本质上是不可能解决的。
• 同步 values-collection 上的所有内容，这至少允许删除，但代价是在键初始查找后的任何并发性。
• 对于较小的惩罚（也许，取决于使用模式？），也许在值集合创建和删除时同步，需要检查是否涵盖了所有内容。

问题：

• 有谁知道比这更好的实现？我们可以更好地组合 MapMaker 的部分，还是需要从头开始编写专门的 ConcurrentHashMultimap？
• 如果很难在这方面做出很大改进，那么这种泄漏在实践中是否可能是一个很大的问题？java.util.HashMap、juc.ConcurrentHashMap 和 ArrayDeque 等著名的集合不会向下调整后备存储的大小，而 ArrayList 也不会自动这样做。只要我们清除对象，我想这会不会太重要。

谢谢

编辑：另请参阅番石榴邮件列表上的讨论。

编辑2：我已经写了这个。请参阅此 Google 代码区以了解实现。我将非常感谢任何尝试它的人的反馈，那里而不是这里。

我认为在 ConcurrentHashMap 的实现中，已经使用了 ReentrantLock。所以不需要使用 ReentrantLock 来访问 ConcurrentHashMap 对象。这只会增加更多的同步开销。任何意见？

我正在编写一些必须处理多个线程的客户端-服务器-应用程序。我有一些服务器，每隔几秒钟发送一次活动数据包。这些服务器在 ConcurrentHashMap 中维护，其中包含它们的 EndPoints 与相应服务器的最后一个活动包到达的时间配对。

现在我有一个线程，它必须“整理”所有在特定时间内没有发送活动数据包的服务器。

我想我不能就那样做，可以吗？

有没有一种方法可以在不为整个循环获取锁的情况下解决这个问题（然后我也必须在其他线程中尊重）？

我需要一个可从多个线程访问的 HashMap。

有两个简单的选项，使用普通的 HashMap 并在其上同步或使用 ConcurrentHashMap。

由于 ConcurrentHashMap 不会阻止读取操作，它似乎更适合我的需求（几乎完全读取，几乎从不更新）。另一方面，无论如何，我希望并发性非常低，所以不应该有阻塞（只是管理锁的成本）。

地图也将非常小（少于十个条目），如果这有所作为的话。

与常规的 HashMap 相比，读写操作的成本要高多少（我假设它们是）？或者，无论读取/更新比率和大小如何，即使可能存在中等级别的并发访问，ConcurrentHashMap 是否总是更好？

我正在阅读文章“ Java 理论与实践：构建更好的 HashMap ”，它对 ConcurrentHashMap 的实现进行了很好的概述。

我还在 Stackoverflow 上找到了一些关于它的讨论。

尽管我的想法是“使用 ConcurrentHashMap 的场景/应用程序/地点是什么”，但我提出疑问。

谢谢

JDK 附带了and的CopyOnWrite*实现，但没有实现，我经常感叹这个事实。我知道还有其他的集合实现有它们，但如果一个作为标准发布就好了。这似乎是一个明显的遗漏，我想知道是否有充分的理由。任何人都知道为什么这被遗漏了吗？SetListMap

如果在并发哈希映射上存在操作，您如何执行安全获取？（与 putIfAbsent 相同）

不好的例子，不是很安全的线程（检查然后采取行动）：

另一个不好的例子是：

这里的可取之处是不要通过同步添加、删除和获取操作来限制它们。

谢谢

我已经阅读了Java Concurrency in Practice并留下了一个问题：当我使用 ConcurrentHashMap 时，我还需要担心本书第一部分中讨论的哪些数据并发问题？以下是我的一个程序中的几个示例：

1. 交易者的当前头寸（一个共享整数，其中“整数”是数学术语）

这个数字代表了一个trader对象当前拥有的东西并定义了它的状态。它必须阅读其位置以知道该做什么（寻找开始一个新位置，或管理当前位置）。 Trader方法在自己的线程上运行。

一个broker对象负责设置trader的位置。每次交易者的一个订单被执行时，它将设置头寸。 Broker方法在自己的线程上运行。

trader和都broker在同一个包中。Position 被实现为 package-private static ConcurrentHashMap。键是交易者对象的 id。值是整数。

包的外部是应用程序。它通过公共吸气剂间接获得交易者的头寸。

位置每隔几分钟最多会更改一次，因此broker不会经常触摸地图。但是，traderand 应用程序会经常读取。此外，我们经常有几个交易者同时阅读地图。

因此，以这种方式使用 ConcurrentHashMap，我不必处理锁定和数据可见性？ConcurrentHashMap 处理所有事情？

2. 市场（买、卖、最后价）

与位置几乎相同的情况，除了现在broker会非常频繁地更新价格（在繁忙时间每秒最多更新 10 次；通常每秒更新几次）。和trader应用程序仍然会频繁读取。地图键现在是指示哪个股票或期货的代码，而值是保存市场价格的对象。

它似乎工作正常，但在阅读 JCIP 之后，我意识到如果事情没有正确实施，程序仍然可能被破坏。这本书讨论了 ConcurrentHashMap，但没有明确告诉我第一部分中的哪些问题我们不再需要手动解决。在这种情况下，我似乎不需要做synchronize任何事情。那是对的吗？

如果我使用并发哈希图并且我有设置和获取值的方法，因为我使用并发哈希图我需要使 getter 和 setter 同步吗？这是多余的吗？一种设计更好吗？

此外，没有同步的并发 hashmap 是否比具有同步 getter 和 setter 的 hashmap 快？这是一个高性能系统

谢谢