LinkedBlockingQueue和ArrayBlockingQueue之間的比較

前言

最近在工作中用到了LinkedBlockingQueue，不過隨後發現了另一個與此用途十分類似的類ArrayBlockingQueue。於是花了點時間，查閱了相關的文章介紹，本篇就來簡單的做個小結，也是為了方便下次查閱。 LinkedBlockingQueue和ArrayBlockingQueue的共性

在講述LinkedBlockingQueue和ArrayBlockingQueue的區別前，我們還是先瞭解下這2個隊列結構間的一些“共性”。

第一，首先它們都繼承了BlockingQueue的介面，也就是說，它們都是阻塞式的隊列，這裡的阻塞情況無外乎2種：一種是隊列滿時阻塞等待，另一種就是隊列空時阻塞等待，前者等待的產生者，後者則是消費者。所以這種結構用在生產者-消費者的使用情境中是比較適用的。還有一點，因為是隊列，所以肯定保證FIFO順序性的。

第二，既然都繼承了BlockingQueue的介面，那麼它們所對外提供的方法也是一致的，add/offer/put，take/poll/remove。這裡面還能夠支援阻塞，非阻塞的調用形式，總體來說還是非常靈活的。 LinkedBlockingQueue和ArrayBlockingQueue的區別

OK，這裡是本文的重點了，也就是二者之間的區別了。

首先第一個區別，ArrayBlockingQueue是有界的，而LinkedBlockingQueue預設是無界的（可以通過指定大小來變為有界）。ArrayBlockingQueue有界就意味著我們使用ArrayBlockingQueue必須指定capacity大小。這樣的話，記憶體空間會直接預先分配好，所以在使用LinkedBlockingQueue無界情況下時要考慮到記憶體實際使用問題，防止記憶體溢出問題的發生。

第二點，鎖使用的比較。ArrayBlockingQueue內部使用1個鎖來控制隊列項的插入、取出操作，而LinkedBlockingQueue則是使用了2個鎖來控制，一個名為putLock，另一個是takeLock，但是鎖的本質都是ReentrantLock。因為LinkedBlockingQueue使用了2個鎖的情況下，所以在一定程度上LinkedBlockingQueue能更好支援高並發的情境操作，這裡指的是並發性上，不是輸送量。

第三點，吞吐效能上的比較。這裡其實會涉及到裡面具體的操作差異的問題。在ArrayBlockingQueue內部，因為是直接使用數組空間的，而且都是預先分配好的，所以操作沒有那麼複雜，而在LinkedBlockingQueue中，是通過鏈表進行維護的，而且每次插入的對象還要轉為Node<>(e)對象，相當於多做了一步操作，但是根據LinkedBlockingQueue的官方描述，它是具有更好吞吐效能的。

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

這裡還提到了一點“less predictable performance”，這點筆者認為應該是它引入了2個鎖來控制插入/取出操作有關，在這點上會比ArrayBlockingQueue要複雜些。但是筆者一直好奇一點，在小規模情境下，是否ArrayBlockingQueue會比LinkedBlockingQueue更適用呢。這個大家可以試試，筆者也還沒試過。