細節決定成敗：從一個故障說說Java的三個BlockingQueue
最近出了個故障，排查的時候耗費了很長的時間，回顧整個排查過程，經驗主義在這里起了不好的作用，直接導致了整個故障排查的時間非常長，這個故障的根本原因在于BlockingQueue用的有問題，順帶展開說說Java中常用的幾個BlockingQueue：ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。
當時故障的現象是應用處理請求的線程池滿了，導致請求處理不了，于是dump線程，看線程都在做什么，結果發現線程都Block在寫日志的地方，以前出現過很多次問題，去線程dump的時候看到也是一堆的block在寫日志，但通常是別的原因引發的，所以這次也是按照這樣的經驗，認為肯定不會是寫日志這個地方的問題，于是各種排查...折騰了N久后，回過頭看發現持有那把日志鎖的地方是自己人寫的代碼，那段代碼在拿到了這個日志鎖后，從線程堆棧上看，block在了ArrayBlockingQueue.put這個地方，于是翻看這段代碼，結果發現這是個1024長度的BlockingQueue，那就意味著如果這個Queue被放了1024個對象的話，put就一定會被block住，而且其實翻代碼的時候能看出寫代碼的同學是考慮到了BlockingQueue如果滿了應該要處理的，代碼里寫著：
- if (blockingQueue.remainingCapacity() < 1) {
- //todo
- }
- blockingQueue.put...
這里兩個悲催的問題，一是這個if判斷完還是直接會走到put，而不是else，二是竟然關鍵的滿了后的處理邏輯還在//todo...
另外我覺得這段代碼還反應了同學對BlockingQueue的接口不太熟，要達到這個效果，不需要這樣先去判斷，更合適的做法是用blockingQueue.offer，返回false再做相應的異常處理。
BlockingQueue是在生產/消費者模式下經常會用到的數據結構，通常常用的主要會是ArrayBlockingQueue、LinkedBlockingQueue和SynchronousQueue。
ArrayBlockingQeue/LinkedBlockingQueue兩者的最大不同主要在于存放Queue中對象方式，一個是數組，一個是鏈表，代碼注釋里也寫到了兩者的不同：
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的時候，如果沒有另外的線程正好并發在offer，也會失敗，這種特殊的模式非常適合用來做要求高響應并且線程出不固定的線程池的Queue。
對于在線業務場景而言，所有的并發，外部訪問阻塞的地方的一個真理就是一定要有超時機制，我不知道見過多少次由于沒有超時造成的在線業務的嚴重故障，在線業務最強調的是快速處理掉一次請求，所以fail fast是在線業務系統設計，代碼編寫中的最重要原則，按照這個原則上面的代碼最起碼明顯犯的錯誤就是用put而不是帶超時機制的offer，或者說如果是不重要的場景，完全就應該直接用offer，false了直接拋異?；蛴涗浵庐惓＜纯?。
對于BlockingQueue這種場景呢，除了超時機制外，還有一個是隊列長度一定要做限制，否則默認的是Integer.MAX_VALUE，萬一代碼出點bug的話，內存就被玩掛了。
說到BlockingQueue，就還是要提下BlockingQueue被用的最多的地方：線程池，Java的ThreadPoolExecutor中有個參數是BlockingQueue，如果這個地方用的是ArrayBlockingQueue或LinkedBlockingQueue，而線程池的coreSize和poolSize不一樣的話，在coreSize線程滿了后，這個時候線程池首先會做的是offer到BlockingQueue，成功的話就結束，這種場景同樣不符合在線業務的需求，在線業務更希望的是快速處理，而不是先排隊，而且其實在線業務最好是不要讓請求堆在排隊隊列里，在線業務這樣做很容易引發雪崩，超出處理能力范圍直接拒絕拋錯是相對比較好的做法，至于在前面頁面上排隊什么這個是可以的，那是另外一種限流機制。
所以說在寫高并發、分布式的代碼時，除了系統設計外，代碼細節的功力是非常非常重要的。
作者：bluedavy
