這篇blog遲到了很久，本來是想寫另一個(gè)跟網(wǎng)絡(luò)相關(guān)bug的查找過程，偷偷懶，寫下最近印象比較深刻的bug。這個(gè)bug是我的同事水寒最終定位到的。
前幾個(gè)月同事報(bào)告稱有一個(gè)線上MQ集群會(huì)同一時(shí)間拋出ArrayIndexOutOfBoundsException這個(gè)異常，也就是數(shù)組越界。查看源碼，除去一些無關(guān)緊要的細(xì)節(jié)大概是這樣子：
public class ConnectionSelector{
private AtomicInteger sets=new AtomicInteger(0);
public void selectConnection(List<Connection> connList){
if(connList==null)｛
return null;
｝
final int size = connList.size();
if (size == 0) {
return null;
}
return connList.get(sets.incrementAndGet() % size);
}
}
很顯然，這里的本意是實(shí)現(xiàn)一個(gè)輪詢的連接選擇器，返回一個(gè)選中的連接。使用AtomicInteger遞增并對(duì)鏈表大小取模，返回結(jié)果索引位置的連接。異常拋出的位置就是我代碼中標(biāo)紅的位置。
顯然，這里有兩種可能，一種情況下是說在執(zhí)行那一行代碼的時(shí)候，connList的大小縮小了（也就是說連接可能被其他線程移出），那么導(dǎo)致取模的結(jié)果越界。另一種可能是取模的結(jié)果本身確實(shí)超過了列表范圍。
第一種情況是完全可能的，因?yàn)榉?wù)器的連接可能隨時(shí)斷開或者重連，但是這種情況相對(duì)非常少見，因此我們這里并沒有對(duì)這個(gè)選擇過程做同步，主要是從性能的角度出發(fā)，偶爾的失敗可以接受。很遺憾的是，我被我的思維慣性誤導(dǎo)了，從來沒有懷疑過第二種情況，總是認(rèn)為是不是真的連接恰巧斷開導(dǎo)致這個(gè)異常，但是卻無法解釋這個(gè)異常發(fā)生后就一直錯(cuò)誤下去，無法自行恢復(fù)。
為什么說思維慣性誤導(dǎo)呢？這里的問題其實(shí)是負(fù)數(shù)取模的問題，對(duì)一個(gè)負(fù)數(shù)進(jìn)行取模，結(jié)果會(huì)是正數(shù)還是負(fù)數(shù)？答案是結(jié)果因語言而異。
我很早以前在使用Ruby的時(shí)候做過測試，負(fù)數(shù)取模結(jié)果為正數(shù)，例如在irb里嘗試下：
>> -1000%3
=> 2
>> -2001%4
=> 3
這個(gè)印象持續(xù)至今，在clojure里結(jié)果也是這樣子：
Clojure 1.2.1
user=> (mod -1000 3)
2
user=> (mod -2001 4)
3
可以再試試python:
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -10000%3
2
>>> -2001%4
3
這三種語言的結(jié)果完全一致，結(jié)果都為正數(shù)。這個(gè)慣性思維延續(xù)到j(luò)ava卻不成立了，可惜我根本沒做測試，讓我們?cè)囅拢?br />
public static void main(final String[] args) {
System.out.println(-1000 % 3);
System.out.println(-2001 % 4);
}
打印結(jié)果為：
-1
-1
果然，在java里負(fù)數(shù)取模的結(jié)果為負(fù)數(shù)，而不是我習(xí)慣性地認(rèn)為是正數(shù)。因此最終的定位到的原因就是sets這個(gè)變量遞增超過Integer.MAX_VALUE后越界變成負(fù)數(shù)了，取模的結(jié)果為負(fù)數(shù)，導(dǎo)致拋出數(shù)組越界的異常，這也解釋了為什么同一個(gè)集群都在同一時(shí)間出問題，因?yàn)檫@個(gè)集群內(nèi)的機(jī)器啟動(dòng)時(shí)間相鄰并且調(diào)用這個(gè)方法次數(shù)相對(duì)平均。
修正問題很簡單，加個(gè)Math.abs就好。 Update:加個(gè)abs是不夠的，因?yàn)镸ath.abs的javadoc提醒了：
Note that if the argument is equal to the value of Integer.MIN_VALUE, the most negative representable int value, the result is that same value, which is negative.
也就是說對(duì)Integer.MIN_VALUE做abs結(jié)果仍然是負(fù)數(shù)。盡管在這個(gè)場景中失敗一次可以接受，但是最好的辦法還是回復(fù)中steven提到的抵消符號(hào)位的做法：
(sets.incrementAndGet() & 0x7FFFFFFF) % size
這個(gè)問題更詳細(xì)的討論后來我找到
這篇博客，作者討論幾種語言和計(jì)算器的這個(gè)問題的結(jié)果，給出了一些結(jié)論。不過我覺的這個(gè)結(jié)論可能也不是那么可靠，特別是對(duì)c/c++來說，很大程度上應(yīng)該還是依賴于實(shí)現(xiàn)，最可靠的辦法還是強(qiáng)制結(jié)果為正。
這個(gè)bug的幾個(gè)教訓(xùn)：
1、首先是第一次出現(xiàn)的時(shí)候沒有引起足夠重視，重啟解決問題后沒有深究。有句玩笑話：99％的程序問題都可以通過重啟解決。但是事實(shí)上問題仍然存在，該發(fā)生的終究還會(huì)發(fā)生。不管你信不信，它就是發(fā)生了，這是一個(gè)奇跡。
2、注意大腦的思維慣性，經(jīng)驗(yàn)主義和教條主義都不可取。最近在讀一本好書《
暗時(shí)間》，大腦誤導(dǎo)我們的手段可是多種多樣。
3、最后就是這個(gè)負(fù)數(shù)取模的結(jié)果因語言而異，不要依賴于特定實(shí)現(xiàn)。