我什么时候应该使用ConcurrentSkipListMap?
在 Java 中,ConcurrentHashMap 提供了更好的多线程解决方案。那么什么时候应该使用ConcurrentSkipListMap呢?是不是冗余?
这两者之间的多线程方面是否共同?
In Java, ConcurrentHashMap
is there for better multithreading
solution. Then when should I use ConcurrentSkipListMap
? Is it a redundancy?
Does multithreading aspects between these two are common?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
这两个类在几个方面有所不同。
ConcurrentHashMap 不保证*作为合同一部分的其操作的运行时间。它还允许调整某些负载因子(大致是同时修改它的线程数)。
另一方面,ConcurrentSkipListMap,保证各种操作的平均 O(log(n)) 性能。它也不支持并发调整。
ConcurrentSkipListMap
还具有许多ConcurrentHashMap
没有的操作:ceilingEntry/Key、floorEntry/Key 等。它还维护排序顺序,否则必须是如果您使用ConcurrentHashMap
,则计算(花费大量费用)。基本上,针对不同的用例提供了不同的实现。如果您需要快速单键/值对添加和快速单键查找,请使用
HashMap
。如果您需要更快的有序遍历,并且可以承受额外的插入成本,请使用SkipListMap
。*虽然我预计实现大致符合 O(1) 插入/查找的一般哈希映射保证;忽略重新哈希
These two classes vary in a few ways.
ConcurrentHashMap does not guarantee* the runtime of its operations as part of its contract. It also allows tuning for certain load factors (roughly, the number of threads concurrently modifying it).
ConcurrentSkipListMap, on the other hand, guarantees average O(log(n)) performance on a wide variety of operations. It also does not support tuning for concurrency's sake.
ConcurrentSkipListMap
also has a number of operations thatConcurrentHashMap
doesn't: ceilingEntry/Key, floorEntry/Key, etc. It also maintains a sort order, which would otherwise have to be calculated (at notable expense) if you were using aConcurrentHashMap
.Basically, different implementations are provided for different use cases. If you need quick single key/value pair addition and quick single key lookup, use the
HashMap
. If you need faster in-order traversal, and can afford the extra cost for insertion, use theSkipListMap
.*Though I expect the implementation is roughly in line with the general hash-map guarantees of O(1) insertion/lookup; ignoring re-hashing
排序、可导航和并发
有关数据结构的定义,请参阅跳过列表。
< code>ConcurrentSkipListMap 存储
Map
按照其键的自然顺序(或您定义的其他键顺序)。因此,它的get
/put
/contains
操作比HashMap
,但为了抵消它支持SortedMap
,NavigableMap
和ConcurrentNavigableMap
接口。Sorted, navigable, and concurrent
See Skip List for a definition of the data structure.
A
ConcurrentSkipListMap
stores theMap
in the natural order of its keys (or some other key order you define). So it'll have slowerget
/put
/contains
operations than aHashMap
, but to offset this it supports theSortedMap
,NavigableMap
, andConcurrentNavigableMap
interfaces.当您 (a) 需要对键进行排序,和/或 (b) 需要可导航地图的第一个/最后一个、头部/尾部和子地图功能时。
ConcurrentHashMap
类实现ConcurrentMap
接口,ConcurrentSkipListMap
。但如果您还想要SortedMap
和NavigableMap
,使用ConcurrentSkipListMap
ConcurrentHashMap
ConcurrentSkipListMap
这是一个表格,指导您了解各种
Map
与 Java 11 捆绑在一起的实现。单击/点击进行缩放。请记住,您可以获得其他
Map
实现以及类似的数据结构,来自其他来源,例如 Google Guava。When you (a) need to keep keys sorted, and/or (b) need the first/last, head/tail, and submap features of a navigable map.
The
ConcurrentHashMap
class implements theConcurrentMap
interface, as doesConcurrentSkipListMap
. But if you also want the behaviors ofSortedMap
andNavigableMap
, useConcurrentSkipListMap
ConcurrentHashMap
ConcurrentSkipListMap
Here is table guiding you through the major features of the various
Map
implementations bundled with Java 11. Click/tap to zoom.Keep in mind that you can obtain other
Map
implementations, and similar such data structures, from other sources such as Google Guava.在性能方面,
skipList
当用作 Map 时 - 似乎慢了 10-20 倍。这是我的测试结果(Java 1.8.0_102-b14,win x32)除此之外 - 比较一对一确实有意义的用例。使用这两个集合实现最近使用的项目的缓存。现在,skipList 的效率看起来更加可疑。
以下是 JMH 的代码(执行为
java -jar target/benchmarks.jar -bm avgt -f 1 -wi 5 -i 5 -t 1
)In terms of performance,
skipList
when is used as Map - appears to be 10-20 times slower. Here is the result of my tests (Java 1.8.0_102-b14, win x32)And additionally to that - use-case where comparing one-to-another really makes sense. Implementation of the cache of last-recently-used items using both of these collections. Now efficiency of skipList looks to be event more dubious.
Here is the code for JMH (executed as
java -jar target/benchmarks.jar -bm avgt -f 1 -wi 5 -i 5 -t 1
)基于工作负载,ConcurrentSkipListMap 可能比使用同步方法的 TreeMap 慢,如 KAFKA-8802 如果需要范围查询。
Based on workloads ConcurrentSkipListMap could be slower than TreeMap with synchronized methods as in KAFKA-8802 if range queries are needed.
ConcurrentHashMap :当您想要基于多线程索引的 get/put 时,仅支持基于索引的操作。 Get/Put 的复杂度为 O(1)
ConcurrentSkipListMap :不仅仅是 get/put 的更多操作,例如按键排序顶部/底部 n 个项目、获取最后一个条目、获取/遍历按键排序的整个映射等。复杂度为 O(log( n)), 所以put性能不如ConcurrentHashMap。它不是带有 SkipList 的 ConcurrentNavigableMap 的实现。
总而言之,当您想要在需要排序功能的地图上执行更多操作而不仅仅是简单的获取和放置时,请使用 ConcurrentSkipListMap。
ConcurrentHashMap : when u want multithreaded index based get/put, only index based operations are supported. Get/Put are of O(1)
ConcurrentSkipListMap : More operations than just get/put, like sorted top/bottom n items by key, get last entry, fetch/traverse whole map sorted by key etc. Complexity is of O(log(n)), So put performance is not as great as ConcurrentHashMap. It't an implementation of ConcurrentNavigableMap with SkipList.
To summarize use ConcurrentSkipListMap when you want to do more operations on map requiring sorted features rather than just simple get and put.