JDK QUEUE隊列

Java  Queue基礎

Queue: 基本上,一個隊列就是一個先入先出(FIFO)的數據結構。java

offer,add區別: 一些隊列有大小限制,所以若是想在一個滿的隊列中加入一個新項,多出的項就會被拒絕。 這時新的 offer 方法就能夠起做用了。它不是對調用 add() 方法拋出一個 unchecked 異常,而只是獲得由 offer() 返回的 false。 數組

poll,remove區別: remove() 和 poll() 方法都是從隊列中刪除第一個元素(head)。remove() 的行爲與 Collection 接口的版本類似, 可是新的 poll() 方法在用空集合調用時不是拋出異常,只是返回 null。所以新的方法更適合容易出現異常條件的狀況。緩存

peek,element區別: element() 和 peek() 用於在隊列的頭部查詢元素。與 remove() 方法相似,在隊列爲空時, element() 拋出一個異常,而 peek() 返回 null。安全

常見非阻塞隊列

ArrayDeque, (數組雙端隊列)數據結構

PriorityQueue, (優先級隊列)多線程

ConcurrentLinkedQueue, (基於鏈表的併發隊列)併發

PriorityQueue 類實質上維護了一個有序列表。加入到 Queue 中的元素根據它們的自然排序(經過其 java.util.Comparable 實現)或者根據傳遞給構造函數的 java.util.Comparator 實現來定位。app

ConcurrentLinkedQueue 是基於連接節點的、線程安全的隊列。併發訪問不須要同步。由於它在隊列的尾部添加元素並從頭部刪除它們,因此只要不須要知道隊列的大小,ConcurrentLinkedQueue 對公共集合的共享訪問就能夠工做得很好。收集關於隊列大小的信息會很慢,須要遍歷隊列。函數

常見阻塞隊列BlockingQueue

ArrayBlockingQueue和LinkedBlockingQueue是兩個最普通也是最經常使用的阻塞隊列,通常狀況下,在處理多線程間的生產者消費者問題,使用這兩個類足以。高併發

DelayQueue, (延期阻塞隊列)(阻塞隊列實現了BlockingQueue接口)

ArrayBlockingQueue, (基於數組的併發阻塞隊列) 底層是數組,有界隊列,若是咱們要使用生產者-消費者模式,這是很是好的選擇。

LinkedBlockingQueue, (基於鏈表的FIFO阻塞隊列)  底層是鏈表,能夠當作無界和有界隊列來使用,因此你們不要覺得它就是無界隊列。

LinkedBlockingDeque, (基於鏈表的FIFO雙端阻塞隊列)

PriorityBlockingQueue, (帶優先級的無界阻塞隊列) 是無界隊列,基於數組,數據結構爲二叉堆,數組第一個也是樹的根節點老是最小值。

SynchronousQueue (併發同步阻塞隊列)自己不帶有空間來存儲任何元素,使用上能夠選擇公平模式和非公平模式。

BlockingQueue的核心方法:

BlockingQueue 對插入操做、移除操做、獲取元素操做提供了四種不一樣的方法用於不一樣的場景中使用:

一、拋出異常;

二、返回特殊值(null 或 true/false,取決於具體的操做);

三、阻塞等待此操做,直到這個操做成功;

四、阻塞等待此操做,直到成功或者超時指定時間。

 

  拋出異常 特殊值 阻塞 超時
插入 add(e) offer(e) put(e) offer(e, time, unit)
刪除 remove() poll() take() poll(time, unit)
獲取 element() peek() not applicable not applicable

 放入數據:

  offer(anObject):表示若是可能的話,將anObject加到BlockingQueue裏,即若是BlockingQueue能夠容納,
    則返回true,不然返回false.(本方法不阻塞當前執行方法的線程)
  offer(E o, long timeout, TimeUnit unit),能夠設定等待的時間,若是在指定的時間內,還不能往隊列中
    加入BlockingQueue,則返回失敗。
  put(anObject):把anObject加到BlockingQueue裏,若是BlockQueue沒有空間,則調用此方法的線程被阻斷
    直到BlockingQueue裏面有空間再繼續.
獲取數據:
  poll(time):取走BlockingQueue裏排在首位的對象,若不能當即取出,則能夠等time參數規定的時間,
    取不到時返回null;
  poll(long timeout, TimeUnit unit):從BlockingQueue取出一個隊首的對象,若是在指定時間內,
    隊列一旦有數據可取,則當即返回隊列中的數據。不然知道時間超時尚未數據可取,返回失敗。
  take():取走BlockingQueue裏排在首位的對象,若BlockingQueue爲空,阻斷進入等待狀態直到
    BlockingQueue有新的數據被加入; 
  drainTo():一次性從BlockingQueue獲取全部可用的數據對象(還能夠指定獲取數據的個數), 
    經過該方法,能夠提高獲取數據效率;不須要屢次分批加鎖或釋放鎖。

 

1. ArrayBlockingQueue
      基於數組的阻塞隊列實現,在ArrayBlockingQueue內部,維護了一個定長數組,以便緩存隊列中的數據對象,這是一個經常使用的阻塞隊列,除了 一個定長數組外,ArrayBlockingQueue內部還保存着兩個整形變量,分別標識着隊列的頭部和尾部在數組中的位置。
   ArrayBlockingQueue在生產者放入數據和消費者獲取數據,都是共用同一個鎖對象,由此也意味着二者沒法真正並行運行,這點尤爲不一樣於 LinkedBlockingQueue;按照實現原理來分析,ArrayBlockingQueue徹底能夠採用分離鎖,從而實現生產者和消費者操做的 徹底並行運行。Doug Lea之因此沒這樣去作,也許是由於ArrayBlockingQueue的數據寫入和獲取操做已經足夠輕巧,以致於引入獨立的鎖機制,除了給代碼帶來額外的複雜性外,其在性能上徹底佔不到任何便宜。 ArrayBlockingQueue和LinkedBlockingQueue間還有一個明顯的不一樣之處在於,前者在插入或刪除元素時不會產生或銷燬任 何額外的對象實例,然後者則會生成一個額外的Node對象。這在長時間內須要高效併發地處理大批量數據的系統中,其對於GC的影響仍是存在必定的區別。而 在建立ArrayBlockingQueue時,咱們還能夠控制對象的內部鎖是否採用公平鎖,默認採用非公平鎖。

2. LinkedBlockingQueue
      基於鏈表的阻塞隊列,同ArrayListBlockingQueue相似,其內部也維持着一個數據緩衝隊列(該隊列由一個鏈表構成),當生產者往隊列 中放入一個數據時,隊列會從生產者手中獲取數據,並緩存在隊列內部,而生產者當即返回;只有當隊列緩衝區達到最大值緩存容量時 (LinkedBlockingQueue能夠經過構造函數指定該值),纔會阻塞生產者隊列,直到消費者從隊列中消費掉一份數據,生產者線程會被喚醒,反之對於消費者這端的處理也基於一樣的原理。而LinkedBlockingQueue之因此可以高效的處理併發數據,還由於其對於生產者端和消費者端分別採用了獨立的鎖來控制數據同步,這也意味着在高併發的狀況下生產者和消費者能夠並行地操做隊列中的數據,以此來提升整個隊列的併發性能。
做爲開發者,咱們須要注意的是,若是構造一個LinkedBlockingQueue對象,而沒有指定其容量大小,LinkedBlockingQueue會默認 一個相似無限大小的容量(Integer.MAX_VALUE),這樣的話,若是生產者的速度一旦大於消費者的速度,也許尚未等到隊列滿阻塞產生,系統內存就有可能已被消耗殆盡了。


3. DelayQueue
      DelayQueue中的元素只有當其指定的延遲時間到了,纔可以從隊列中獲取到該元素。DelayQueue是一個沒有大小限制的隊列,所以往隊列中插入數據的操做(生產者)永遠不會被阻塞,而只有獲取數據的操做(消費者)纔會被阻塞。
使用場景:
  DelayQueue使用場景較少,但都至關巧妙,常見的例子好比使用一個DelayQueue來管理一個超時未響應的鏈接隊列。

4. PriorityBlockingQueue
      基於優先級的阻塞隊列(優先級的判斷經過構造函數傳入的Compator對象來決定),但須要注意的是PriorityBlockingQueue並不會阻塞數據生產者,而只會在沒有可消費的數據時,阻塞數據的消費者。所以使用的時候要特別注意,生產者生產數據的速度絕對不能快於消費者消費數據的速度, 不然時間一長,會最終耗盡全部的可用堆內存空間。在實現PriorityBlockingQueue時,內部控制線程同步的鎖採用的是公平鎖。5. SynchronousQueue       一種無緩衝的等待隊列,相似於無中介的直接交易,有點像原始社會中的生產者和消費者,生產者拿着產品去集市銷售給產品的最終消費者,而消費者必須親自去 集市找到所要商品的直接生產者,若是一方沒有找到合適的目標,那麼對不起,你們都在集市等待。相對於有緩衝的BlockingQueue來講,少了一箇中 間經銷商的環節(緩衝區),若是有經銷商,生產者直接把產品批發給經銷商,而無需在乎經銷商最終會將這些產品賣給那些消費者,因爲經銷商能夠庫存一部分商 品,所以相對於直接交易模式,整體來講採用中間經銷商的模式會吞吐量高一些(能夠批量買賣);但另外一方面,又由於經銷商的引入,使得產品從生產者到消費者 中間增長了額外的交易環節,單個產品的及時響應性能可能會下降。   聲明一個SynchronousQueue有兩種不一樣的方式,它們之間有着不太同樣的行爲。公平模式和非公平模式的區別:  若是採用公平模式:SynchronousQueue會採用公平鎖,並配合一個FIFO隊列來阻塞多餘的生產者和消費者,從而體系總體的公平策略;   但若是是非公平模式(SynchronousQueue默認):SynchronousQueue採用非公平鎖,同時配合一個LIFO(後進先出法 Last In First Out )隊列來管理多餘的生產者和消費者,然後一種模式,若是生產者和消費者的處理速度有差距,則很容易出現飢渴的狀況,便可能有某些生產者或者是消費者的數據永遠都得不處處理。

相關文章
相關標籤/搜索