notFull.signal（）; //隊列沒滿，當然可以解鎖了

　　}

　　} finally {

　　putLock.unlock（）;

　　}

　　if （c == 0）

　　signalNotEmpty（）;//這個方法里發出了notEmpty.signal（）;

　　return c 》= 0;

　　}

　　public E poll（） {

　　final AtomicInteger count = this.count;

　　if （count.get（） == 0）

　　return null;

　　E x = null;

　　int c = -1;

　　final ReentrantLock takeLock = this.takeLock;出隊當然用takeLock

　　takeLock.lock（）;

　　try {

　　if （count.get（） 》 0） {

　　x = dequeue（）;//出隊

　　c = count.getAndDecrement（）;//隊長度-1

　　if （c 》 1）

　　notEmpty.signal（）;//隊列沒空，解鎖

　　}

　　} finally {

　　takeLock.unlock（）;

　　}

　　if （c == capacity）

　　signalNotFull（）;//這個方法里發出了notFull.signal（）;

　　return x;

　　}

　　看看源代碼發現和上面ArrayBlockingQueue的很類似，關鍵的問題在于：為什么要用兩個ReentrantLockputLock和takeLock？

　　我們仔細想一下，入隊操作其實操作的只有隊尾引用last，并且沒有牽涉到head。而出隊操作其實只針對head，和last沒有關系。那么就是說入隊和出隊的操作完全不需要公用一把鎖，所以就設計了兩個鎖，這樣就實現了多個不同任務的線程入隊的同時可以進行出隊的操作，另一方面由于兩個操作所共同使用的count是AtomicInteger類型的，所以完全不用考慮計數器遞增遞減的問題。

　　另外，還有一點需要說明一下：await（）和singal（）這兩個方法執行時都會檢查當前線程是否是獨占鎖的當前線程，如果不是則拋出java.lang.IllegalMonitorStateException異常。所以可以看到在源碼中這兩個方法都出現在Lock的保護塊中。

　　-------------------------------我是分割線--------------------------------------

　　下面再來說說ConcurrentLinkedQueue，它是一個無鎖的并發線程安全的隊列。

　　以下部分的內容參照了這個帖子

　　對比鎖機制的實現，使用無鎖機制的難點在于要充分考慮線程間的協調。簡單的說就是多個線程對內部數據結構進行訪問時，如果其中一個線程執行的中途因為一些原因出現故障，其他的線程能夠檢測并幫助完成剩下的操作。這就需要把對數據結構的操作過程精細的劃分成多個狀態或階段，考慮每個階段或狀態多線程訪問會出現的情況。

　　ConcurrentLinkedQueue有兩個volatile的線程共享變量：head，tail。要保證這個隊列的線程安全就是保證對這兩個Node的引用的訪問（更新，查看）的原子性和可見性，由于volatile本身能夠保證可見性，所以就是對其修改的原子性要被保證。

　　下面通過offer方法的實現來看看在無鎖情況下如何保證原子性：

　　Java代碼

　　public boolean offer（E e） {

　　if （e == null） throw new NullPointerException（）;

　　Node n = new Node（e， null）;

　　for （;;） {

　　Node t = tail;

　　Node s = t.getNext（）;

　　if （t == tail） { //------------------------------a

　　if （s == null） { //---------------------------b

　　if （t.casNext（s， n）） { //-------------------c

　　casTail（t， n）; //------------------------d

　　return true;

　　}

　　} else {

　　casTail（t， s）; //----------------------------e

　　}

　　}

　　}