疏忽的杯具

   项目出现问题，小概率情况下不能处理数据。分析日志及代码，确定是某块负责load balance的代码有问题。多个server会接收相同数据，在避免数据重复处理及server负载均衡的情况下，在server的逻辑入口做判断，抛弃本server不能处理的数据。

简单代码呀

int hashcode = "ea34dfc3-4a16-455d-846b-ed351c691c99".hashCode();
private boolean needToHandle(int hashcode, int serverCount, int serverNumber) {
      return hashcode % serverCount == (serverNumber - 1);
}

单台server的时候不经过这段代码，且这段代码看起来是正常的。所以呢，单台server测试正常，等QA多台server测试的时候就杯具了。

以前翻看《Jave Puzzlers》的时候，第一个puzzler就是关于取模运算时，奇偶数判断存在正负数的问题。那个问题只是模2，当模其它值的时候，问题依然存在。一个负被模数(UUID)如果不是模数(serverCount)的整数倍，那么取模的结果就是负数。

引用

-8 % 3 = -2;  -8 % 4 = 0;

这个问题我是知道的，出现Bug就是因为没有想到为什么UUID的hash值为负数呢。我们的UUID本是一个string,经过string.hashCode()方法后，这个值可能会溢出，而hashCode方法返回是int，它会截取低32位并返回。经过hash后的UUID结果就可正可负，原因就在这，以前没想过。

哎，对这个问题的总结是：测试一定得完备；细节决定成败。切记！切记！

PS:String hashCode的实现方式，对字符串中的每个char循环相加

int h = 0;
char[] val = value;
for (int i = 0; i < len; i++) {
      h = 31*h + val[off++];
}
return h;

补充下：解决上面hashCode为负的情况，一般的解决方法是Math.abs(hashCodeValue)，但这种方法是有小问题的。

Math.abs(Integer.MIN_VALUE) = Integer.MIN_VALUE

因为Integer.MAX_VAUE是2^31 - 1（0x7fffffff），而Integer.MIN_VALUE是-2^31(0x80000000)，即没有与Integer.MIN_VALUE相对应的绝对值，对它取绝对值时会返回原值。

更好的解决方法是

hashCodeValue & 0x7fffffff

可以保证为正。

评论

2 楼 langyu 2010-06-28  

mercyblitz 写道

String hashCode 的实现还是会出现重复。

这个知道的，“Aa”与“BB”就是重复的。String的算法问题，不会影响什么吧。如果需要惟一值，就获取字符串的MD5，SHA1等摘要值

1 楼 mercyblitz 2010-06-22  

String hashCode 的实现还是会出现重复。