StackOverflow發(fā)展到目前，已經(jīng)成為了全球開發(fā)者的金礦。它能夠幫助我們找到在各個(gè)領(lǐng)域遇到的問(wèn)題的最有用的解決方案，同時(shí)我們也會(huì)從中學(xué)習(xí)到很多新的東西。這篇文章是在我們審閱了StackOverflow上最流行的Java問(wèn)題以及答案后從中挑出來(lái)的。即使你是一個(gè)有豐富經(jīng)驗(yàn)的開發(fā)者，也能從中學(xué)到不少東西。

一、分支預(yù)測(cè)

問(wèn)題鏈接：

https://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array

StackOverflow上最多投票的一個(gè)Java問(wèn)題是：為什么處理一個(gè)排序數(shù)組要比非排序數(shù)組快的多。為了回答這個(gè)問(wèn)題，你需要使用分支預(yù)測(cè)(branch prediction)。分支預(yù)測(cè)是一種架構(gòu)，旨在通過(guò)在真實(shí)的路徑發(fā)生前猜測(cè)某一分支的下一步來(lái)提升處理過(guò)程。

分支在這里即一個(gè)if語(yǔ)句。這樣的話，如果是一個(gè)排序數(shù)組，那么分支預(yù)測(cè)將會(huì)進(jìn)行，否則不會(huì)進(jìn)行。

StackOverflow上的一個(gè)回答者，鏈接：http://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array/11227902#11227902

試圖使用鐵路和火車來(lái)簡(jiǎn)單介紹這個(gè)概念。假設(shè)你在鐵軌連接處要決定火車要走哪條路，你會(huì)選擇左邊還是右邊？你可以攔住火車，然后問(wèn)司機(jī)該往那里，但是這樣會(huì)讓整個(gè)過(guò)程變慢。因此你只能去猜正確的方向，那么如何去猜呢？最好的辦法就是通過(guò)觀察目前這個(gè)火車每次經(jīng)過(guò)時(shí)的路線，推測(cè)出正確的方向。

這就是分支預(yù)測(cè)：識(shí)別模式并使用它。

不幸的是，這個(gè)問(wèn)題的提問(wèn)者是分支預(yù)測(cè)失敗的受害者。因?yàn)樗姆种](méi)有任何可以識(shí)別出的模式，所以預(yù)測(cè)出的行為是隨機(jī)的。

二、Java中的安全

問(wèn)題鏈接：

http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords-in-java

另一個(gè)流行的Java問(wèn)題是：為什么在Java中有關(guān)密碼的地方更加喜歡使用char[]而不是String？其實(shí)原始的問(wèn)題更加具體一些，就是問(wèn)的在Swing中，password控件有一個(gè)getPassword方法(返回char[]而不是getText()返回的String)。

其實(shí)這里不用驚訝-這是一個(gè)安全問(wèn)題。String是不可變的，意味著一旦它被創(chuàng)建了，那么你就不可能去修改它。這也意味著在GC之前，你對(duì)這些數(shù)據(jù)不能做任何處理。因此，只要有人能夠訪問(wèn)你的內(nèi)存，那么String就有可能被他獲取到。

這也就是為什么要使用char數(shù)組。你可以顯示地清除數(shù)據(jù)或者覆蓋它。這樣密碼這種敏感數(shù)據(jù)即使GC還沒(méi)有進(jìn)行也不會(huì)再在系統(tǒng)留下痕跡。

三、異常

問(wèn)題鏈接：

http://blog.takipi.com/the-top-10-exceptions-types-in-production-java-applications-based-on-1b-events/

即使很多開發(fā)者傾向于忽略對(duì)受檢異常的處理，StackOverflow上仍然有很多關(guān)于異常的問(wèn)題。其中一個(gè)最流行的問(wèn)題是：什么是NullPointerException，我該怎么處理它？對(duì)此，我們并沒(méi)有感到驚訝，因?yàn)檫@個(gè)問(wèn)題也是在生產(chǎn)環(huán)境的Java應(yīng)用中排名第一的異常。

實(shí)際上，當(dāng)NullPointerException(或者其他exception)在系統(tǒng)出現(xiàn)的時(shí)候，我們可以發(fā)出一個(gè)告警。因?yàn)檫@種異常一般情況下都是業(yè)務(wù)代碼邏輯有問(wèn)題造成(筆者注)。

四、為什么這段代碼使用隨機(jī)字符串打印出了”hello world”

問(wèn)題鏈接：

http://stackoverflow.com/questions/15182496/why-does-this-code-using-random-strings-print-hello-world

這個(gè)問(wèn)題給出了下面的代碼，并打印出了”hello world”。

System.out.println(randomString(-229985452) + " " + randomString(-147909649)); 
 
public static String randomString(int i){ 
    Random ran = new Random(i); 
    StringBuilder sb = new StringBuilder(); 
    while (true) 
    { 
        int k = ran.nextInt(27); 
        if (k == 0) 
            break; 
 
        sb.append((char)('`' + k)); 
    } 
 
    return sb.toString(); 
} 

其實(shí)，選擇一組隨機(jī)的整數(shù)并不是隨機(jī)的。給定一個(gè)seed參數(shù)(在這個(gè)例子中是-229985452和-147909649), 那么每次隨機(jī)，同樣的seed則會(huì)產(chǎn)生同樣的輸出。

Random(-229985452).nextInt(27)產(chǎn)生的前六個(gè)數(shù)字：8, 5, 12, 12, 15, 0

Random(-147909649).nextInt(27)產(chǎn)生的前六個(gè)數(shù)字：23, 15, 18, 12, 4, 0

這樣，最終輸出的就是”hello world”。

五、為什么兩個(gè)時(shí)間戳相減(in 1927)得出一個(gè)奇怪的結(jié)果？

問(wèn)題鏈接：

http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result

public static void main(String[] args) throws ParseException { 
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");   
    String str3 = "1927-12-31 23:54:07";   
    String str4 = "1927-12-31 23:54:08";   
    Date sDt3 = sf.parse(str3);   
    Date sDt4 = sf.parse(str4);   
    long ld3 = sDt3.getTime() /1000;   
    long ld4 = sDt4.getTime() /1000; 
    System.out.println(ld4-ld3); 
} 

按說(shuō)上面的代碼最后的結(jié)果應(yīng)該是1，但實(shí)際的輸出卻是353。其實(shí)，這是一個(gè)時(shí)區(qū)的問(wèn)題。1927年12月31號(hào)24:00，上海時(shí)間往回調(diào)整了5分鐘52秒，因此”1927-12-31 23:54:08”發(fā)生了兩次，Java將后面一次實(shí)例化成了本地的這個(gè)時(shí)間。因此和前一秒的差距成了353。

我們需要指出，如果你試著來(lái)運(yùn)行這段代碼，結(jié)果并不一定是353。Jon Skeet指出了這一點(diǎn)，鏈接：

http://stackoverflow.com/a/6841479/5982245

在時(shí)區(qū)數(shù)據(jù)庫(kù)項(xiàng)目2014版中，這個(gè)改變的時(shí)間點(diǎn)改到了1900-12-31，因此成了344秒的差距。

六、無(wú)法被捕獲的ChuckNorrisException

問(wèn)題鏈接：

http://stackoverflow.com/questions/13883166/uncatchable-chucknorrisexception

這里有一個(gè)很明顯的問(wèn)題：如果有exception被拋出，但是沒(méi)有任何辦法去catch，那么應(yīng)用會(huì)崩潰嗎？或者如這個(gè)問(wèn)題所問(wèn)：是否可以寫一段Java代碼讓一個(gè)假設(shè)的java.lang.ChuckNorrisException無(wú)法被捕獲。

答案是可以，但是這里有一個(gè)”但是”。你可以編譯一段代碼拋出一個(gè)ChuckNorrisException，但是在Runtime時(shí)動(dòng)態(tài)生成一個(gè)并不繼承于Throwable接口的ChuckNorrisException類。當(dāng)然，為了讓這個(gè)過(guò)程可以進(jìn)行，你需要關(guān)閉掉字節(jié)碼驗(yàn)證。jtahlborn給出了完整的解決辦法。鏈接：

http://stackoverflow.com/a/13883510/5982245

七、哈希表

哈希表是另外一個(gè)在StackOverflow上流行的問(wèn)題系列。許多用戶都想要知道所有集合類之間的區(qū)別，什么時(shí)候該使用哪種集合。

迭代順序是主要考慮的因素。使用HashMap則忽略了所有的順序信息，也就是獲取元素的順序和你插入元素的順序是沒(méi)有任何關(guān)系的；使用TreeMap則會(huì)得到一個(gè)排序好的迭代集合；使用LinkedHashMap則是一個(gè)FIFO的順序。

如果你還是對(duì)這些感到困惑，這里有一個(gè)相關(guān)說(shuō)明的圖表可以參考(Rebel Labs制作。鏈接：

http://zeroturnaround.com/wp-content/uploads/2016/04/Java-Collections-cheat-sheet.png。

八、總結(jié)

對(duì)于Java，其實(shí)關(guān)鍵的不在于你懂多少，而是在于你可以一直學(xué)到更多的東西。StackOverflow不僅在code上的一些問(wèn)題可以幫助我們，也有助于我們回過(guò)頭來(lái)去深入地學(xué)習(xí)一些我們已經(jīng)知道的知識(shí)。