SynchronousQueue为何未实现TransferQueue接口？

• 核心语义不匹配：TransferQueue的设计允许元素在队列中暂存，等待后续消费者来取——哪怕暂时没有匹配的消费者，元素也能先存在队列里。但SynchronousQueue的本质是无缓冲的直接线程配对，它根本没有存储元素的能力，任何生产操作必须立刻找到对应的消费线程，否则要么阻塞要么失败。如果硬要让它实现TransferQueue，像hasWaitingConsumer()这类方法的返回逻辑会非常尴尬：如果返回true，意味着有等待的消费者，但SynchronousQueue里的等待线程是双向配对关系，单独说“等待消费者”不符合它的模型；如果返回false，又和实际存在等待线程的情况矛盾。
• 接口方法存在冗余与冲突：TransferQueue继承自BlockingQueue，虽然SynchronousQueue也实现了BlockingQueue，但它的offer()、add()等方法在无匹配线程时直接失败的行为，和TransferQueue部分方法的预期不符。比如TransferQueue的tryTransfer(E e, long timeout, TimeUnit unit)方法，语义是“等待一段时间看有没有消费者接收”，但SynchronousQueue的超时等待逻辑其实和put()带超时的逻辑完全重复，强行实现会让接口方法显得多余，还可能误导开发者以为它支持元素缓存。
• 设计定位完全不同：SynchronousQueue是为极致低延迟的直接交换场景设计的，内部连队列存储结构都没有，所有操作都是基于线程直接配对完成。而TransferQueue（比如LinkedTransferQueue）是通用型实现，兼顾了直接交换和队列缓存两种场景。让SynchronousQueue实现TransferQueue，会模糊它的定位，开发者可能会错误地用它来做需要缓存的场景，违背它的设计初衷。
• 历史兼容性的限制：TransferQueue是Java 7才新增的接口，而SynchronousQueue在Java 5就已经存在。如果后续修改让它实现TransferQueue，可能会打破现有代码的预期——有些老代码就是依赖它无缓冲的特性，突然多了TransferQueue的方法，容易让开发者误解它的能力，引入不必要的bug。

内容的提问来源于stack exchange，提问作者Carl Mastrangelo