ArrayBlockingQueue和LinkedBlockingQueue源码解析

ArrayBlockingQueue和LinkedBlockingQueue都是java.util.concurrent包中的阻塞队列。

阻塞队列就是支持阻塞的插入和移除的容量,即在容量满时往BlockingQueue中添加数据时会造成阻塞,当容量为空时取元素操作会阻塞。内部的阻塞队列是通过重入锁ReenterLock和Condition条件队列实现的。

看名字就可以知道他们的底层数据结构不同:

        ArrayBlockingQueue是由数组结构组成的有界阻塞队列

        LinkedBlockingQueue是由链表结构组成的有界阻塞队列

下面看看源码:

        publicclass ArrayBlockingQueue<E> extends AbstractQueue<E>

       implements BlockingQueue<E>, java.io.Serializable {

   /**

    * Serialization ID. This class relies on default serialization

    * even for the items array, which is default-serialized, even if

    * it is empty. Otherwise it could not be declared final, which is

    * necessary here.

    */

   private static final long serialVersionUID = -817911632652898426L;

   /** The queued items */

   final Object[] items;

   /** items index for next take, poll, peek or remove */

   int takeIndex;

   /** items index for next put, offer, or add */

   int putIndex;

   /** Number of elements in the queue */

   int count;

   /*

    * Concurrency control uses the classic two-condition algorithm

    * found in any textbook.

    */

   /** Main lock guarding all access */

   final ReentrantLock lock;

   /** Condition for waiting takes */

   private final Condition notEmpty;

    /** Condition for waiting puts */

   private final Condition notFull;

        可以清楚ArrayBlockingQueue是一个阻塞式的队列,继承自AbstractQueue,。底层以数组的形式保存数据。而且实现的队列中的锁是没有分离的,即生产和消费用的是同一个锁。

实现的队列中在生产和消费的时候,是直接将对象插入或移除的。

public class LinkedBlockingQueue<E>extends AbstractQueue<E>

       implements BlockingQueue<E>, java.io.Serializable {

   private static final long serialVersionUID = -6903933977591709194L;

   /*

    * A variant of the "two lock queue" algorithm.  The putLock gates

    * entry to put (and offer), and has an associated condition for

    * waiting puts.  Similarly for thetakeLock.  The "count" field

    * that they both rely on is maintained as an atomic to avoid

    * needing to get both locks in most cases. Also, to minimize need

    * for puts to get takeLock and vice-versa, cascading notifies are

    * used. When a put notices that it has enabled at least one take,

    * it signals taker. That taker in turn signals others if more

    * items have been entered since the signal. And symmetrically for

    * takes signalling puts. Operations such as remove(Object) and

    * iterators acquire both locks.

    *

    * Visibility between writers and readers is provided as follows:

    *

    * Whenever an element is enqueued, the putLock is acquired and

    * count updated.  A subsequentreader guarantees visibility to the

    * enqueued Node by either acquiring the putLock (via fullyLock)

    * or by acquiring the takeLock, and then reading n = count.get();

    * this gives visibility to the first n items.

    *

    * To implement weakly consistent iterators, it appears we need to

    * keep all Nodes GC-reachable from a predecessor dequeued Node.

    * That would cause two problems:

    * - allow a rogue Iterator to cause unbounded memory retention

    * - cause cross-generational linking of old Nodes to new Nodes if

    *   a Node was tenured while live,which generational GCs have a

    *   hard time dealing with,causing repeated major collections.

    * However, only non-deleted Nodes need to be reachable from

    * dequeued Nodes, and reachability does not necessarily have to

    * be of the kind understood by the GC. We use the trick of

    * linking a Node that has just been dequeued to itself.  Such a

    * self-link implicitly means to advance to head.next.

    */

   /**

    * Linked list node class

    */

   static class Node<E> {

       E item;

       /**

        * One of:

        * - the real successor Node

        * - this Node, meaning the successor is head.next

        * - null, meaning there is no successor (this is the last node)

        */

       Node<E> next;

        Node(E x) { item = x; }

    }

   /** The capacity bound, or Integer.MAX_VALUE if none */

   private final int capacity;

   /** Current number of elements */

   private final AtomicInteger count = new AtomicInteger(0);

   /**

    * Head of linked list.

    * Invariant: head.item == null

    */

   private transient Node<E> head;

   /**

    * Tail of linked list.

    * Invariant: last.next == null

    */

   private transient Node<E> last;

   /** Lock held by take, poll, etc */

   private final ReentrantLock takeLock = new ReentrantLock();

   /** Wait queue for waiting takes */

   private final Condition notEmpty = takeLock.newCondition();

   /** Lock held by put, offer, etc */

   private final ReentrantLock putLock = new ReentrantLock();

   /** Wait queue for waiting puts */

   private final Condition notFull = putLock.newCondition();

 LinkedBlockingQueue也是一个阻塞式的队列,继承自AbstractQueue,。底层以链表结构保存数据。注意实现的队列中的锁是分离的,即生产用的是putLock,消费是takeLock。这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据,以此来提高整个队列的并发性能。  实现的队列中在生产和消费的时候,需要把枚举对象转换为Node<E>进行插入或移除,这产生了新的对象,造成了一定的开销。

猜你喜欢

转载自blog.csdn.net/qq_27327855/article/details/80542574