Guava 的 EvictingQueue 的替代品，带有 @Beta 注释
在我的项目的一个关键部分，它基本上允许控制器异步接收对象，放入 Queue，由一个线程从队列中依次处理，然后服务响应，较旧的已处理对象将保留在队列中，直到插入新的项目.
In a critical part of my project which basically allows objects to be received by a controller asynchronously, put into a Queue, processed sequentially from the queue one at a time by a thread, then service responds, older processed objects are kept in the queue until newer item insertion.
回到过去(几个月前)，我的 Queue 实现是使用 Guava 的 EvictingQueue，它现在被标记为 @Beta，因此这部分应用程序可能会在未来的 Guava 版本中中断.
Back in time (months ago), my Queue implementation for solving this particular business specific issue behind this was to use Guava's EvictingQueue, which now is marked as @Beta, and so this part of the application can break in future Guava releases.
private final Queue<SomeRandomBusinessObject> items = Queues.synchronizedQueue(EvictingQueue.create(queueSize));
EvictingQueue 是否有任何线程安全和固定大小 替代方案来实现这一目标?
Are there any thread-safe and fixed-size alternatives to EvictingQueue to achieve this goal?
推荐答案
你的帖子有几个不准确/错误，所以让我们试着找到共同点.
There are couple of inaccuracies / mistakes in your post, so let's just try to find common ground.
首先，Guava 中的任何新功能从一开始都被注释为 @Beta，EvictingQueue in 15.0(链接到 15.0 文档).所以几个月前你可能错过了这个事实，但没关系，因为......
First, any new feature in Guava is annotated as @Beta from the beginning, same is true for EvictingQueue in 15.0 (this links to 15.0 docs). So you probably missed that fact couple months ago, but that's OK, because...
...@Beta 并不是说它会在没有任何通知的情况下更改——相反，前段时间，在社区的一些反馈之后，Guava 开发人员建立了相当严格的关于什么和什么时候可以改变的政策.请参阅 PhilosophyExplained wiki 页面，上面写着(强调我的):
...@Beta doesn't really mean it'll be changed without any notice -- on the contrary, some time ago, after some feedback from the community, Guava devs established pretty strict policy about what and when can be changed. See PhilosophyExplained wiki page, which says (emphasis mine):
Beta API 代表 Guava 功能，无论出于何种原因，我们都没有准备好冻结:因为这些方法可能找不到足够的用户，因为它们可能会被移动，因为它们的用途可能太窄而无法将它们包含在 Guava 中.
Beta APIs
Beta APIs represent Guava features that we aren't ready to freeze for whatever reason: because the methods might not find enough users, because they might be moved, because their uses might be too narrow to include them in Guava.
也就是说，@Beta API 已经过全面测试和支持，并且受到 Guava 其他人所接受的所有关心和喜爱.
That said, @Beta APIs are fully tested and supported, and treated with all the care and affection that the rest of Guava receives.
这意味着 EvictingQueue 的质量并不比它不是测试版功能"时差.
This means EvictingQueue quality is not worse than if it wasn't a "beta feature".
@Beta注解最大的内涵是被注解的类或方法可以随时更改.它们可以随时以任何方式修改，甚至删除.如果您的代码本身就是一个库(即，它用于您无法控制的用户的 CLASSPATH)，则不应使用beta API，除非您重新打包它们(例如使用 ProGuard).
The biggest connotation of the
@Betaannotation is that annotated classes or methods are subject to change. They can be modified in any way, or even removed, at any time. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard).
这可能是您在谈到未来的刹车"时提出的问题，但是......
This could be the concern you brought up when talking about "braking up in the future", but...
综上所述，@Beta 功能往往保持相对稳定.如果我们决定删除 @Beta 功能，我们通常会在一个版本中弃用它，然后再删除它.
All this said,
@Betafeatures tend to remain relatively stable. If we decide to delete a@Betafeature, we will typically deprecate it for one release before deleting it.
所以它不会无声无息地发生(据我观察，通常会有不止一个版本被弃用).
So it won't happen silently (as far as I observed, usually there's more than one release with deprecating though).
这给我带来了最后一点:
Which brings me the the last point:
另一方面，如果您想从 @Beta 中删除某些内容，请提交问题.我们通常会推广 @Beta 只有在特别要求的时候，所以如果你不问，它就不会发生.
On the other hand, if you want something taken out of
@Beta, file an issue. We generally promote features out of@Betaonly when it's specifically requested, so if you don't ask, it won't happen.
总结一下:我建议你提交一张票以推广 EvictingQueue 并使其成为非 @Beta，这样可以消除任何疑虑.另一方面，EvictingQueue 的实现非常简单且独立，因此如果它被删除(不太可能)，您可以重新打包它(即使用 ProGuard)，甚至将代码复制到您的项目中(包含所有许可证).
To sum up: I'd suggest you to file a ticket to promote EvictingQueue and make it non-@Beta, which would remove any doubts about it. On the other hand, the EvictingQueue's implementation is quite simple and standalone, so if it's removed (unlikely) you can repakckage it (i.e. use ProGuard) or even copy the code to your project (with all the licenses).
相关文章