java中的LinkedBlockingDeque

问题一: LinkedBlockingDeque是否减少了竞争？

public class LinkedBlockingDeque<E>
    extends AbstractQueue<E>
    implements BlockingDeque<E>, java.io.Serializable {

    ...

    /** Main lock guarding all access */
    final ReentrantLock lock = new ReentrantLock();

    /** Condition for waiting takes */
    private final Condition notEmpty = lock.newCondition();

    /** Condition for waiting puts */
    private final Condition notFull = lock.newCondition();

    ...

    public void putFirst(E e) throws InterruptedException {
        ...
        final ReentrantLock lock = this.lock;
        lock.lock();
        ....
    }

    public void putLast(E e) throws InterruptedException {
        ...
        final ReentrantLock lock = this.lock;
        lock.lock();
        ...
    }

    public E takeFirst() throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lock();
        ...
    }

    public E takeLast() throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lock();
        ...
    }
    
}

由源码可以看出，LinkedBlockingDeque 中只有一个锁，多线程下不管是从队头或者队尾，入队、出队都是用的这把锁，竞争并没有减少小。

LinkedBlockingDeque是一个由链表结构组成的双向阻塞队列，即可以从队列的两端插入和移除元素。双向队列因为多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。

这句话是大概是有问题的，反而LinkedBlockingQueue中使用了两把锁，将入队与出队分开，相对于LinkedBlockingDeque减少了多线程下的竞争。

public class LinkedBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, java.io.Serializable {
    ...
    /** Lock held by take, poll, etc */
    private final ReentrantLock takeLock = new ReentrantLock();

    /** Lock held by put, offer, etc */
    private final ReentrantLock putLock = new ReentrantLock();
    ...
}

问题2：

        众所周知1：线程池的任务队列是一个阻塞队列。

        众所周知2：ForkJoinPool中每个线程有自己的一个任务队列，当线程自己任务处理完后，会有工作窃取一个过程。

        众所周知3：ForkJoinPool中的任务队列就是一个双端队列。

        由问题一中的代码来看，使用双端队列效率反而不如普通队列。ForkJoinPool 使用的双端队列是什么？

public class ForkJoinPool extends AbstractExecutorService {
    ...
    volatile WorkQueue[] workQueues;     // main registry
    ...
}



static final class WorkQueue {
    ...
    ForkJoinTask<?>[] array;   // the elements (initially unallocated)
    ...
}

可以看到ForkJoinPool中的任务队列是WorkQueue这个内部类，并且WorkQueue没有实现BlockingDeque接口。

再来看他的一个关键方法

    final ForkJoinTask<?> poll() {
            ForkJoinTask<?>[] a; int b; ForkJoinTask<?> t;
            while ((b = base) - top < 0 && (a = array) != null) {
                int j = (((a.length - 1) & b) << ASHIFT) + ABASE;
                t = (ForkJoinTask<?>)U.getObjectVolatile(a, j);
                if (base == b) {
                    if (t != null) {
                        if (U.compareAndSwapObject(a, j, t, null)) {
                            base = b + 1;
                            return t;
                        }
                    }
                    else if (b + 1 == top) // now empty
                        break;
                }
            }
            return null;
        }


    

发现ForkJoinPool并没有使用锁的方式来实现任务队列，而是使用sun.misc.Unsafe的cas操作。

这种方式是否减少了竞争？

众所周知4: compare and swap 是比较与交换。

一个线程从队头出队，一个线程从队尾出队，理论上两个线程除最后一个元素外基本不会有交际。所以ForkJoinPool的双端队列确实是减少了竞争的。