[[272320]]

最近出了個故障，排查的時候耗費了很長的時間，回顧整個排查過程，經(jīng)驗主義在這里起了不好的作用，直接導(dǎo)致了整個故障排查的時間非常長，這個故障的根本原因在于BlockingQueue用的有問題，順帶展開說說Java中常用的幾個BlockingQueue：ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。

當(dāng)時故障的現(xiàn)象是應(yīng)用處理請求的線程池滿了，導(dǎo)致請求處理不了，于是dump線程，看線程都在做什么，結(jié)果發(fā)現(xiàn)線程都Block在寫日志的地方，以前出現(xiàn)過很多次問題，去線程dump的時候看到也是一堆的block在寫日志，但通常是別的原因引發(fā)的，所以這次也是按照這樣的經(jīng)驗，認(rèn)為肯定不會是寫日志這個地方的問題，于是各種排查...折騰了N久后，回過頭看發(fā)現(xiàn)持有那把日志鎖的地方是自己人寫的代碼，那段代碼在拿到了這個日志鎖后，從線程堆棧上看，block在了ArrayBlockingQueue.put這個地方，于是翻看這段代碼，結(jié)果發(fā)現(xiàn)這是個1024長度的BlockingQueue，那就意味著如果這個Queue被放了1024個對象的話，put就一定會被block住，而且其實翻代碼的時候能看出寫代碼的同學(xué)是考慮到了BlockingQueue如果滿了應(yīng)該要處理的，代碼里寫著：

if (blockingQueue.remainingCapacity() < 1) {  
//todo  
}  
blockingQueue.put... 

這里兩個悲催的問題，一是這個if判斷完還是直接會走到put，而不是else，二是竟然關(guān)鍵的滿了后的處理邏輯還在//todo...

另外我覺得這段代碼還反應(yīng)了同學(xué)對BlockingQueue的接口不太熟，要達到這個效果，不需要這樣先去判斷，更合適的做法是用blockingQueue.offer，返回false再做相應(yīng)的異常處理。

BlockingQueue是在生產(chǎn)/消費者模式下經(jīng)常會用到的數(shù)據(jù)結(jié)構(gòu)，通常常用的主要會是ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。

ArrayBlockingQeue/LinkedBlockingQueue兩者的最大不同主要在于存放Queue中對象方式，一個是數(shù)組，一個是鏈表，代碼注釋里也寫到了兩者的不同：

Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications.

SynchronousQueue是一個非常特殊的BlockingQueue，它的模式是在offer的時候，如果沒有另外一個線程正在take或poll的話，那么offer就會失敗;在take的時候，如果沒有另外的線程正好并發(fā)在offer，也會失敗，這種特殊的模式非常適合用來做要求高響應(yīng)并且線程出不固定的線程池的Queue。

對于在線業(yè)務(wù)場景而言，所有的并發(fā)，外部訪問阻塞的地方的一個真理就是一定要有超時機制，我不知道見過多少次由于沒有超時造成的在線業(yè)務(wù)的嚴(yán)重故障，在線業(yè)務(wù)最強調(diào)的是快速處理掉一次請求，所以fail fast是在線業(yè)務(wù)系統(tǒng)設(shè)計，代碼編寫中的最重要原則，按照這個原則上面的代碼最起碼明顯犯的錯誤就是用put而不是帶超時機制的offer，或者說如果是不重要的場景，完全就應(yīng)該直接用offer，false了直接拋異?；蛴涗浵庐惓＜纯?。

對于BlockingQueue這種場景呢，除了超時機制外，還有一個是隊列長度一定要做限制，否則默認(rèn)的是Integer.MAX_VALUE，萬一代碼出點bug的話，內(nèi)存就被玩掛了。

說到BlockingQueue，就還是要提下BlockingQueue被用的最多的地方：線程池，Java的ThreadPoolExecutor中有個參數(shù)是BlockingQueue，如果這個地方用的是ArrayBlockingQueue或LinkedBlockingQueue，而線程池的coreSize和poolSize不一樣的話，在coreSize線程滿了后，這個時候線程池首先會做的是offer到BlockingQueue，成功的話就結(jié)束，這種場景同樣不符合在線業(yè)務(wù)的需求，在線業(yè)務(wù)更希望的是快速處理，而不是先排隊，而且其實在線業(yè)務(wù)最好是不要讓請求堆在排隊隊列里，在線業(yè)務(wù)這樣做很容易引發(fā)雪崩，超出處理能力范圍直接拒絕拋錯是相對比較好的做法，至于在前面頁面上排隊什么這個是可以的，那是另外一種限流機制。

所以說在寫高并發(fā)、分布式的代碼時，除了系統(tǒng)設(shè)計外，代碼細節(jié)的功力是非常非常重要的。

作者：bluedavy