项目出现问题,小概率情况下不能处理数据。分析日志及代码,确定是某块负责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
可以保证为正。
分享到:
相关推荐
Java编码易疏忽的十个问题
工作疏忽本职检讨书.doc
孩子在家安全别疏忽.docx
小学数学数学神探疏忽的罪证
微小的疏忽 生命的代价.pdf
质检工作疏忽的检讨书.doc
一时的疏忽 一生的痛.docx
小学数学数学神探武彦三郎的疏忽
工作失职、工作疏忽的检讨书范文.doc
税务风险就藏在疏忽大意之处.docx
家庭装修知识装中央空调6小点别疏忽整理.pdf
本文主要讲了单片机开发人员的几个容易疏忽的问题点,希望对你的学习有所帮助。
家庭装修知识装中央空调6小点别疏忽终稿.pdf
-2021疏忽检讨书模板___ --条据书信.docx
部分计算机三级网络技术填空题(易疏忽常考的).doc
部分计算机三级网络技术填空题(易疏忽常考的).pdf
行业-电子政务-切换感测以防止电机因疏忽而起动.zip
在新产品试产中,经常出现因为RD人员的设 计“疏忽”导致试产失败。这个疏忽要加上引号,是因为这并不是真正的粗心造成的,而是对生产工艺的不熟悉而导致的。为了避免各位做RD的朋友出现同样的错误,或为了更好的...