问题描述
在我项目的关键部分，该部分基本上允许控制器异步接收对象，将其放入Queue中，然后一次由一个线程从队列中依次处理，然后服务响应，较旧的处理对象会一直保留在队列中，直到插入新的项目为止。
回到过去（几个月前），我用于解决此特定业务特定问题的Queue实现是使用Guava的evictingQueue（现在标记为@Beta），因此该应用程序的这一部分可能会在将来的Guava版本中中断。
private final Queue<SomeRandomBusinessObject> items = Queues.synchronizedQueue(evictingQueue.create(queueSize));
evictingQueue是否有任何线程安全和固定大小的替代方案来实现此目标？
解决方法
您的帖子中存在一些错误/错误，所以让我们尝试找出共同点。
首先，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），甚至将代码复制到您的项目中（具有所有许可证）