在看LinkedBlockingQueue源码的时候发现了一个问题。一个BlockingQueue实际上是由一个链表以及对应的put和poll方法组成的。
下面列出了源码中的put方法。
public void put(E e) throws InterruptedException { if (e == null) throw new NullPointerException(); int c = -1; Node<E> node = new Node(e); final ReentrantLock putLock = this.putLock; final AtomicInteger count = this.count; putLock.lockInterruptibly(); try { while (count.get() == capacity) { notFull.await(); } enqueue(node); c = count.getAndIncrement(); if (c + 1 < capacity) notFull.signal(); } finally { putLock.unlock(); } // 这里通过判断c是否为0来决定是否唤醒notEmpty // c是之前锁putLock时获得的变量，takeLock并没有锁 // c是否可能会是过期变量呢？ if (c == 0) signalNotEmpty(); }
问题就在最后的这个signalNotEmpty()上了，这个方法的功能是解开notEmpty这个Condition（Condition是ReentrantLock中的概念，也就是对象锁），代码如下：
private void signalNotEmpty() { final ReentrantLock takeLock = this.takeLock; takeLock.lock(); try { notEmpty.signal(); } finally { takeLock.unlock(); } }
功能很简单，先锁住takeLock，然后唤醒takeLock中notEmpty这个Condition。
put方法中如果c为0（c的意思是put调用之前的QueueCount）就调用signalNotEmpty()，但是判断if (c == 0)这句话时却并没有加任何的锁，也就是说别的线程完全有机会在put执行到c = count.getAndIncrement()之后将queue又一次取空，而put方法的最后只是通过判断已经过时的c变量就将notEmpty解开了。有可能导致notEmpty的误唤醒。然后来看一下take方法是否做了保护。 public E take() throws InterruptedException { E x; int c = -1; final AtomicInteger count = this.count; final ReentrantLock takeLock = this.takeLock; takeLock.lockInterruptibly(); try { while (count.get() == 0) { // 这里如果count为0就await， // 但是就像之前说的，可能被误唤醒 notEmpty.await(); } // 如果实际queue里什么都没有，那么就有问题了 x = dequeue(); c = count.getAndDecrement(); if (c > 1) notEmpty.signal(); } finally { takeLock.unlock(); } if (c == capacity) signalNotFull(); return x; }实际的模型是这样的，线程A、B、C。A是put的，B、C是take的。
首先count是0，A开始put，
A执行到将count增加为1的时候B拿走了这个元素，然后C开始take，此时C在判断notEmpty的时候block住了。
这个时候A误将notEmpty解锁。C被唤醒，同时队列也是空的。
这种微妙的巧合。因为然是有takeLock锁的，所以B和C虽是两个线程，其实也是串行。实际出问题的可能性就是A线程只执行两行方法的时间，B和C两个串行的线程却执行了超多步骤。
