疏忽的杯具

项目出现问题，小概率情况下不能处理数据。分析日志及代码，确定是某块负责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)的整数倍，那么取模的结果就是负数。
[quote] -8 % 3 = -2; -8 % 4 = 0;[/quote] 这个问题我是知道的，出现Bug就是因为没有想到为什么UUID的hash值为负数呢。我们的UUID本是一个string,经过string.hashCode()方法后，这个值可能会溢出，而hashCode方法返回是int，它会截取低32位并返回。经过hash后的UUID结果就可正可负，原因就在这，以前没想过。

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

[color=brown]PS:String hashCode的实现方式，对字符串中的每个char循环相加[/color]

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

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

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

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

[color=red]更好的解决方法是[/color]

hashCodeValue & 0x7fffffff

[color=red]可以保证为正。[/color]