适用于读取密集型工作负载的快速且符合人体工程学的并发哈希表。
特征
- 符合人体工程学的无锁 API — 不再有死锁！
- 强大的原子操作。
- 在异步上下文中无缝使用。
- 极具可扩展性，低延迟读取（参见性能）。
- 所有操作的延迟均可预测。
- 高效内存使用，并由 提供支持的垃圾收集功能seize。
并发哈希表关注几个重要的属性：
- 读取吞吐量/延迟
- 写入吞吐量/延迟
- 内存使用情况
读应该具有极低的延迟，并且永远不会被慢写阻止
papaya 的目标是服务于读取密集型的工作负载。
另一个重要的考虑因素是拥有一个易于使用的 API。虽然 papaya 可能在内部使用锁，但经过仔细考虑，该 API 是无锁的，不可能出现死锁。
比较
目前有许多并发哈希表包。但是，与 papaya 相比，它们中的大多数在读取吞吐量和可预测延迟方面有所欠缺。此外，异步支持是一项很难找到的功能。但是，在某些情况下，您可能需要考虑使用其他包。
- dashmap的设计非常简单，建立在[url=https://github.com/rust-lang/hashbrown]hashbrown[/url]之上。它还与 的 API 非常相似std::collections::HashMap。对于写入繁重的工作负载，它可能提供更好的性能。在内存使用方面，它的开销也较低。
- scc与 dashmap 类似，但分片桶锁更加激进。对于写入密集型工作负载，它可能应该是您的首选，尽管代码本身似乎相当复杂且难以审计。
- flurry是一个封闭寻址表，具有条带锁但无锁读取。但是，由于分配器压力，它存在性能和内存使用问题。对于大多数工作负载，papaya 总体上应该比 flurry 表现更好。
- evmap非常适合读取量极高的用例。但是，它具有最终一致性，并且写入成本相对较高。即使对于 99% 的读取量大的工作负荷，可扩展性也会受到影响。
- leapfrog性能出色，但仅限于 64 位Copy值。这种限制在学术文献中很常见，并且 leapfrog 会针对任意值类型回退到自旋锁，这对于通用映射来说很不幸。