12个版本 (稳定)
使用旧Rust 2015
2.2.2 | 2019年2月27日 |
---|---|
2.2.0 | 2017年4月5日 |
2.1.1 | 2017年3月6日 |
2.1.0 | 2017年2月10日 |
0.1.2 | 2017年2月4日 |
在并发中排名第1069
每月下载量20,678
在不到47个crates中使用
59KB
1K SLoC
并发哈希表。
此crate实现了基于桶级别多读锁的并发哈希表。它具有出色的性能特征¹,并支持调整大小、就地修改等。
API直接从std::collections::HashMap
派生,使其感觉非常熟悉。
¹请注意,它严重依赖于您的程序的行为,但在大多数情况下,它确实非常好。在某些(罕见)情况下,您可能需要原子哈希表。
工作原理
chashmap
不是无锁的,但它将锁分布在整个映射上,使得锁争用(这可能会使访问变得昂贵)非常罕见。
哈希表由所谓的“桶”组成,每个桶定义了表中的潜在条目。某个键值对的桶由键的哈希值确定。通过为每个桶持有读/写锁,我们确保您通常只需一个或两个锁定子例程即可插入、读取、修改等。
有一个特殊情况:重新分配。当表填满到几乎没有空闲桶时(注意,这是“非常少”,而不是“没有”,因为负载因子不应该太高,因为它会影响性能),在重新散列表时获取全局锁。这非常低效,但这种情况很少发生,由于容量具有自适应性质,它仅在映射刚刚初始化时发生几次。
冲突解决
当两个哈希值发生冲突时,它们不能共享同一个桶,因此必须有一个算法可以解决冲突。在我们的情况下,我们使用线性探测,这意味着我们取它后面的桶,并重复,直到找到空闲的桶。
这种方法远非理想,但像Robin-Hood哈希这样的更优方法在并发结构中表现不佳(如果有的话)。
API
如果您习惯了libstd哈希表实现,API应该感觉非常熟悉。它们共享许多方法,并且我已经仔细确保所有与libstd中具有相似名称的项目在语义和行为上匹配。
依赖关系
~1MB
~17K SLoC