Lucene 4.0 BytesRefHash的一个bug
来源:互联网 发布:如何参加淘宝嘉年华 编辑:程序博客网 时间:2024/05/18 01:09
线上搜索忽然发现一堆死循环线程,最后全部卡在内存索引的BytesRefHashState的查找方法get上,而这个哈希表实现基本参考了lucene-core中的BytesRefHash方法。
这个再散列方法比较特别,inc = ((code >> 8) + code) | 1,code += inc,既不是线性探测也不是二次探测,哈希表的长度为2的幂,并且保证哈希表负载因子小于0.5。我理解这里不使用链表解决冲突是为了节约内存,不用二次探测和线性探测是为了避免聚集和二次聚集,但这同样带来了缓存不友好的问题,最重要的是是否会死循环?
模拟了一下,果然有死循环:
public static void main(String[] args) { int code = 0; HashMap<Integer, Integer> stepMap = new HashMap<Integer, Integer>(); int inc = 0, period = 0; for (; ;) { if ((period % 10000000) == 0) { System.err.println("Period=" + period + ",Size=" + stepMap.size()); } inc = (((code >> 8) + code) | 1); code += inc; if (!stepMap.containsKey(code)) { stepMap.put(code, period); ++period; } else { int oldStep = stepMap.get(code); System.err.println(String.format("Current period=%d, oldStep=%d, currentCode=%d", period, oldStep, code)); return; } } }输出:
Current period=72350, oldStep=23220, currentCode=1542835881
也就是hashCode为1542835881时,经过49130次哈希,就会回到原来位置,只要表长超过98260就会出现问题。
翻了一下最新的lucene 6.6.0版本,BytesRef实现已经变更:哈希方法改为murmurhash3,冲突解决方式改为线性探测。更好的哈希方法避免聚集,线性探测增加缓存友好。
具体改动为(Lucene-5604):https://issues.apache.org/jira/browse/LUCENE-5604
阅读全文
0 0
- Lucene 4.0 BytesRefHash的一个bug
- lucene全文检索的一个小BUG
- lucene 中文分词器中的一个Bug
- Lucene 的一个程序
- 一个简单的lucene例子
- 一个简单的Lucene例子
- 微软的一个bug?
- OracleParameter 的一个bug
- FireFox的一个bug
- 微软的一个BUG
- Tencent 的一个Bug
- 一个ComboBox的Bug
- WindowsXP的一个Bug
- QQ的一个BUG
- JCreator的一个BUG
- Word2007的一个bug
- hibernate3的一个bug
- ICTCLAS的一个bug
- 阿里云服务器购买的流程和步骤,以及如何领取优ecs服务器惠券
- git的简单操作图解
- hadoop入门第六篇:Hive实例
- java中String的一些理解
- TensorFlow框架(5)之机器学习实践
- Lucene 4.0 BytesRefHash的一个bug
- 拨开字符编码的迷雾--编译器如何处理文件编码
- Linux之用户态与内核态
- Java常量池理解与总结
- 小福利 —— 实时更新的页面小时钟
- LintCode 68.二叉树的前序遍历
- bootstrap怎么设置下拉菜单不点击,改成鼠标悬停直接显示下拉菜单
- Python初学——窗口视窗Tkinter
- AT24C32读取数据一直为0xFF