本文对比了无锁哈希表（基于开放地址法和CAS实现）与带读写锁的GNU hash_map在并发场景下的性能。在不同利用率下，无锁哈希表展现出显著的性能优势，但高利用率时冲突可能导致性能下降。测试环境为Intel E5620 CPU和4GB内存，测试压力为2读2写线程处理大量数据。未来可能的改进方向包括动态调整哈希表大小以提高内存利用率。
可爱的作者称之为世界上最简单最快的无锁哈希表，我姑且也起这个名字。
本文的工作主要在于测试 （gnu的hash_map+读写锁）vs （无锁哈希表），我的比较只比较运行时间，不比较内存开销。
这个是作者原文： http://preshing.com/20130605/the-worlds-simplest-lock-free-hash-table/
实现这个无锁的哈希表，最主要的技术要点在于：
1、用了开放地址法实现哈希表，实际内存开销会大于拉链法
2、用了CAS(compare and swap)语义实现小于等于8byte变量的原子操作
我的测试环境：
CPU： Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
MEMORY： 4G
测试压力：2个线程读2个线程写，每个读/写(2<<22)的数据量。
测试结果：
1、无锁哈希表的利用率为50%（预分配的空间只填满25%）：那么LockfreeHashtable完成读写的时间GnuHashmap的一半；
2、若无锁哈希表的利用率为25%：那么LockfreeHashtable完成读写的时间GnuHashmap的1/10；
3、如果无锁哈希表的利用率为100%，那么将会耗费大量的时间在解决冲突，找到合适的位置来放置新的key-value，性能将会急剧下降，惨不忍睹。
两个声明：
1)gnu的hash_map是可以预分配bucket的数量的，通过构造函数设置。在本测试中，无论
最低0.47元/天 解锁文章
951
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
