#hash-map #map #lock #locking #parking-lot

chashmap

快速、功能丰富的并发哈希表API

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

Download history 2820/week @ 2024-03-14 3575/week @ 2024-03-21 3533/week @ 2024-03-28 3718/week @ 2024-04-04 4084/week @ 2024-04-11 5039/week @ 2024-04-18 4488/week @ 2024-04-25 3982/week @ 2024-05-02 6168/week @ 2024-05-09 3944/week @ 2024-05-16 4282/week @ 2024-05-23 4203/week @ 2024-05-30 4840/week @ 2024-06-06 5048/week @ 2024-06-13 6084/week @ 2024-06-20 3955/week @ 2024-06-27

每月下载量20,678
在不到47个crates中使用

MIT许可

59KB
1K SLoC

并发哈希表。

此crate实现了基于桶级别多读锁的并发哈希表。它具有出色的性能特征¹,并支持调整大小、就地修改等。

API直接从std::collections::HashMap派生,使其感觉非常熟悉。

¹请注意,它严重依赖于您的程序的行为,但在大多数情况下,它确实非常好。在某些(罕见)情况下,您可能需要原子哈希表。

工作原理

chashmap不是无锁的,但它将锁分布在整个映射上,使得锁争用(这可能会使访问变得昂贵)非常罕见。

哈希表由所谓的“桶”组成,每个桶定义了表中的潜在条目。某个键值对的桶由键的哈希值确定。通过为每个桶持有读/写锁,我们确保您通常只需一个或两个锁定子例程即可插入、读取、修改等。

有一个特殊情况:重新分配。当表填满到几乎没有空闲桶时(注意,这是“非常少”,而不是“没有”,因为负载因子不应该太高,因为它会影响性能),在重新散列表时获取全局锁。这非常低效,但这种情况很少发生,由于容量具有自适应性质,它仅在映射刚刚初始化时发生几次。

冲突解决

当两个哈希值发生冲突时,它们不能共享同一个桶,因此必须有一个算法可以解决冲突。在我们的情况下,我们使用线性探测,这意味着我们取它后面的桶,并重复,直到找到空闲的桶。

这种方法远非理想,但像Robin-Hood哈希这样的更优方法在并发结构中表现不佳(如果有的话)。

API

如果您习惯了libstd哈希表实现,API应该感觉非常熟悉。它们共享许多方法,并且我已经仔细确保所有与libstd中具有相似名称的项目在语义和行为上匹配。

依赖关系

~1MB
~17K SLoC