Java LinkedTransferQueue线程安全吗？

并发链接队列的Javadoc明确声明它是无界线程安全队列。然而，javadoc for linked transfer queue只提到队列的无界性，并没有提到线程安全

---

我指的不是转移方式

---

生产者调用add方法，消费者调用poll方法

简而言之，答案是肯定的，类j.u.c.LinkedTransferQueue是线程安全的。因为集合类是线程安全的，所以您可以从任何线程安全地调用它的任何方法，包括add和poll

javadoc中的以下文字应被视为证明：

内存一致性影响：与其他并发集合一样，在将对象放入LinkedTransferQueue之前，线程中的操作发生在从另一个线程中的LinkedTransferQueue访问或删除该元素之后的操作之前

---

此外，j.u.c.BlockingQueue在单线程环境中没有多大意义。我的意思是，您可以使用它，但还有更轻量级的解决方案，比如简单的j.u.Queue接口。BlockingQueue的主要应用程序区域是生产者-消费者应用程序，消费者可以阻止等待下一个元素，因为当前元素被阻止，所以下一个元素可能只来自另一个线程。因为j.u.c.TransferQueue扩展了它，所以它的实现也应该是线程安全的

规则是：它说它是线程安全的吗？是的：那么它应该是线程安全的。否：那么假设它不是。我相信这一点，但需要可靠的参考是的，它是线程安全的。我不是指传输方法，而是添加Vs轮询方法内存一致性不同于线程安全性。需要知道并行调用add和poll是否安全，并确保poll不会返回陈旧信息或某些中间状态。关于阻塞队列，linkedBlockingQueue或ArrayBlockingQueue的add/offer/put代码使用锁对象来保持一致性并避免争用情况。LinkedTransferQueue中的添加/提供代码不使用此方法。请检查代码。@AmrishPandey我同意内存一致性和线程安全性是不同的术语，但我个人认为谈论前者而不考虑后者没有任何意义。也许我错了。关于LinkedTransferQueue-您是否查看了类内文档中描述的实现详细信息-使用Slack的双队列概述？乍一看，我可以说这个实现依赖于CAS和线程驻留。该实现基于算法，但有一些改进。我已经看到了CAS代码。我关心的是，若在CAS语句之前调用poll，那个么我将返回一个尚未添加的元素，在理想情况下，它可能是tail元素。我没有调试好它。我寻找源代码或参考文档，但并没有发现任何证明或反对线程安全的东西LinkedTransferQueue@AmrishPandey:java.util.concurrent包中几乎没有一个类使用术语“线程安全”。什么样的线程安全，是不包括在保证一个发生之前的关系，你有什么想法？您对“关注点”的描述是不可理解的。在以前，原子性和同步是不同的。没有成果的讨论