AtomicReferenceFieldUpdater怀疑
我创建了一个适合我的concurrnetHashtable，它与concurrentHashMap略有不同，并且我使用AtomicReferenceFieldUpdater进行CASNext操作(通常支持归档存储，但这样我们也可以执行CASNext )，那么我走的路对吗？虽然我通常在这个concurrentHashTable中比锁定哈希表获得更好的性能，但有时事情不会成功。
所以我得出了以下结论：
如果可用处理器的数量大于哈希表中可用存储桶的数量，则获得锁争用的可能性更高，因此在这种情况下，concurrentHashTable将比锁方法工作得更好，当然，如果读取很多(日志显示85-90%的读取操作)，那么它很适合使用。因此，请建议我，我是否走在正确的道路上，并正确地假设了一切？
如果你有时间，请看这个页面上的代码，哈希表中的code ，我正在做插入，如果元素还没有出现的话…那么告诉我这是否是一种正确的无锁方法？
回答 2
Stack Overflow用户
发布于 2013-02-02 04:56:03
不是一个直接的答案，但是如果你想改进化学管理，可以看看Cliff Click博士写的：here
除此之外，如果不知道你要解决的是什么，就很难帮助你……
Stack Overflow用户
发布于 2011-05-17 19:50:08
在并发散列映射中，有3个主要操作需要考虑:添加元素、删除元素和重新散列
在删除和添加时，只需使用CaS就足够简单了
然而，重新散列将引入左右竞争，这可能导致数据被丢弃，元素对于某些操作、infinite loops是不可见的，这是很难正确的，并且在整个表上使用r/w锁要容易得多。
https://stackoverflow.com/questions/6029967
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号