在我的项目的一个关键部分，它基本上允许控制器异步接收对象，放入Queue，由一个线程从队列中依次处理，然后服务响应，较旧的处理对象是保留在队列中，直到插入新的项目。
回到过去（几个月前），我的 Queue 实现解决这个特定的业务特定问题是使用 Guava 的 EvictingQueue，现在标记为 @Beta，所以这部分应用程序可以在未来的 Guava 版本中中断。
private final Queue<SomeRandomBusinessObject> items = Queues.synchronizedQueue(EvictingQueue.create(queueSize));
是否有任何线程安全和固定大小替代EvictingQueue 来实现这一目标？
【问题讨论】：
标签： java spring-boot queue guava
您的帖子中有几个不准确/错误，所以让我们试着找到共同点。
首先，Guava 中的任何新功能从一开始就被注释为@Beta，EvictingQueue in 15.0 也是如此（此链接到 15.0 文档）。所以几个月前你可能错过了这个事实，但没关系，因为......
...@Beta 并不意味着它会在没有任何通知的情况下进行更改——相反，前段时间，在社区的一些反馈之后，Guava 开发人员制定了非常严格的政策，关于什么和什么时候可以被改变。见PhilosophyExplained wiki page，上面写着（强调我的）：
测试版 API
Beta API 代表 Guava 功能，无论出于何种原因，我们都没有准备好冻结：因为这些方法可能找不到足够的用户，因为它们可能会被移动，因为它们的用途可能太窄而无法将它们包含在 Guava 中。
也就是说，
@BetaAPI 已经过全面测试和支持，并且受到 Guava 其他人所接受的所有关怀和喜爱。
这意味着EvictingQueue 的质量并不比它不是“测试版功能”时差。
@Beta注解最大的内涵是被注解的类或方法可能会发生变化。 它们可以随时以任何方式修改，甚至删除。如果您的代码本身就是一个库（即，它用于您无法控制的用户的 CLASSPATH），则不应使用beta API，除非您重新打包它们（例如使用 ProGuard）。
这可能是您在谈到“未来的刹车”时提出的问题，但是......
综上所述，
@Beta功能往往保持相对稳定。如果我们决定删除@Beta功能，我们通常会在一个版本中弃用它，然后再删除它。
所以它不会无声无息地发生（据我观察，通常会有不止一个版本被弃用）。
这给我带来了最后一点：
另一方面，如果您想从
@Beta中删除某些内容，请提交问题。我们通常仅在特别要求时才从@Beta中推广功能，所以如果您不这样做别问，不会发生的。
总结一下：我建议您提交一张票以宣传EvictingQueue，并将其设为非@Beta，这样可以消除任何疑虑。另一方面，EvictingQueue 的实现非常简单且独立，因此如果它被删除（不太可能），您可以重新打包它（即使用 ProGuard），甚至将代码复制到您的项目（使用所有许可证）。
【讨论】：