Lucene 4.0 BytesRefHash的一个bug

线上搜索忽然发现一堆死循环线程，最后全部卡在内存索引的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