为何仅ArrayBlockingQueue与SynchronousQueue具备公平性策略？

这个问题问到点子上了！其实核心差异源于这两种队列的底层实现逻辑、设计目标，以及JDK团队在性能与功能上的权衡，咱们具体来说：

1. ArrayBlockingQueue：基于单锁的有界结构天然适配公平锁 #

ArrayBlockingQueue是用固定大小的数组实现的有界队列，它的入队、出队操作共享同一把ReentrantLock锁。而ReentrantLock本身就支持公平/非公平模式：

• 公平模式下，锁会严格按照线程等待的先后顺序分配，完美契合队列FIFO（先进先出）的核心特性；
• 实现成本极低，直接复用ReentrantLock的公平性机制就行，不需要额外复杂设计。

反观其他队列比如LinkedBlockingQueue，它用了两把分离的锁（入队锁和出队锁）来提升并发性能。如果要支持公平性，不仅两把锁都要改成公平锁，还要协调入队、出队线程的等待顺序，复杂度会大幅上升，而且会抵消掉双锁带来的性能优势。JDK团队认为这种场景下，性能收益远大于公平性的需求，所以没提供公平选项。

2. SynchronousQueue：无容量特性决定了它对公平配对的需求 #

SynchronousQueue是一个没有任何容量的队列——每一个put()操作必须等待对应的take()操作，反之亦然，本质是线程之间的直接数据传递。

• 它的公平模式依赖一个LinkedBlockingQueue来维护等待的线程，保证先到的线程先配对；
• 非公平模式则用栈结构，允许后来的线程插队，性能更高。

这种设计是因为SynchronousQueue经常被用于线程池的工作队列（比如CachedThreadPool），有些场景下需要严格的线程配对顺序（比如任务必须按提交顺序执行），所以提供公平选项是刚需。而其他类似的TransferQueue（比如LinkedTransferQueue），设计目标更偏向灵活的多生产者多消费者传递，对严格顺序的需求没那么强烈，所以也没支持公平性。

3. 性能与场景的权衡：大部分队列不需要公平性 #

公平性虽然能保证线程唤醒的顺序，但会带来明显的性能损耗：公平锁需要维护有序的等待队列，线程唤醒时不能插队，这会降低整体吞吐量。

• 像PriorityBlockingQueue、DelayQueue这类队列，本身的核心逻辑是按优先级/延迟时间排序，线程唤醒顺序完全由队列元素的规则决定，公平性（线程等待顺序）对它们来说没有意义；
• 大部分普通生产者消费者场景，用户更关注队列的吞吐量和效率，而非线程唤醒的严格顺序，所以默认非公平且不提供选项是更合理的选择。

内容的提问来源于stack exchange，提问作者Code Complete