应用错误收集

时间：2010-10-17 02:01:02

标签： java multithreading hashmap concurrenthashmap java.util.concurrent

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

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

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

地图也将非常小（十个条目下），如果这有所不同。

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

答案 0 :(得分：6)

另一方面，我希望无论如何都要求非常低的并发性，所以应该没有阻塞（只需要管理锁的成本）。

获取和发布 untend Java互斥锁（原始锁定）的成本微乎其微。因此，如果您认为争用的可能性非常低，那么简单的HashMap可能是您最好的选择。

但这都是猜想。除非并且直到您实际分析了您的应用程序，否则花在推测优化上的所有时间很可能（*）浪费时间。

^{* ...除非你有真的良好的直觉。}

答案 1 :(得分：2)

与HashMap相比，CHM为使用Atomic *操作支付了一定的罚款。多少？猜猜看...在你的应用程序中测量...; - ）

如果您发现自己确实存在性能问题，那么对于＆lt; 10条目可能会比java.util土地上组装的任何解决方案更便宜的非常专业的解决方案，但我不会跳到那个直到你知道你有性能问题。

答案 2 :(得分：2)

就吞吐量和性能而言，开销通常可以忽略不计。

另一方面，ConcurrentHashMap（在实例级别）的内存占用量略大于HashMap。如果你有大量的小型CHM，这个开销可能会增加。

答案 3 :(得分：0)

CHM的主要问题：除非您更改c-tor呼叫，否则它不能很好地扩展，但大多数情况下它不会自动扩展可用核心。