快速答案是肯定的，它们是线程安全的。但是不要让它在那里…
首先，一个小的内部管理
BlockingQueue是一个接口，任何不是线程安全的实现都将破坏书面合同。您包括的链接是指
linkedBlockingQueue，它具有一定的灵巧性。
您包含的链接引起了一个有趣的观察，是的，其中有两个锁
linkedBlockingQueue。但是，它无法理解，实际上正在处理“简单”实现会被犯规的极端情况，这就是为什么take和put方法比起初期望的要复杂的原因。
linkedBlockingQueue进行了优化，以避免在读取和写入时使用相同的锁，这减少了争用，但是对于正确的行为，它依赖于队列不为空。当队列中包含元素时，推送和弹出点不在内存的同一区域，可以避免争用。但是，当队列为空时，则无法避免争用，因此需要额外的代码来处理这种常见的“边缘”情况。这是代码复杂度和性能/可伸缩性之间的常见折衷。
接下来的问题是，如何
linkedBlockingQueue知道队列何时为空/不为空，从而处理线程呢？答案是，它使用
AtomicInteger和
Condition作为两个额外的并发数据结构。所述
AtomicInteger用于检查队列的长度是否是零，并且条件是用于等待一个信号时，队列可能是所希望的状态，以通知一个等待的线程。这种额外的协调确实会产生开销，但是在测量中已显示，在增加并发线程数时，此技术的开销低于使用单个锁引入的争用。
下面，我从复制了代码，
linkedBlockingQueue并添加了解释它们如何工作的注释。在较高级别上，
take()首先将所有其他呼叫锁定
take()，然后
put()根据需要发出信号。
put()以类似的方式工作，首先阻止所有其他呼叫
put()，然后
take()在必要时发出信号。
从
put()方法：
// putLock coordinates the calls to put() only; further coordination // between put() and take() follows below putLock.lockInterruptibly(); try { // block while the queue is full; count is shared between put() and take() // and is safely visible between cores but prone to change between calls // a while loop is used because state can change between signals, which is // why signals get rechecked and resent.. read on to see more of that while (count.get() == capacity) { notFull.await(); } // we know that the queue is not full so add enqueue(e); c = count.getAndIncrement(); // if the queue is not full, send a signal to wake up // any thread that is possibly waiting for the queue to be a little // emptier -- note that this is logically part of 'take()' but it // has to be here because take() blocks itself if (c + 1 < capacity) notFull.signal(); } finally { putLock.unlock(); } if (c == 0) signalNotEmpty();从
take()
takeLock.lockInterruptibly(); try { // wait for the queue to stop being empty while (count.get() == 0) { notEmpty.await(); } // remove element x = dequeue(); // decrement shared count c = count.getAndDecrement(); // send signal that the queue is not empty // note that this is logically part of put(), but // for thread coordination reasons is here if (c > 1) notEmpty.signal(); } finally { takeLock.unlock(); } if (c == capacity) signalNotFull();
