Java 番石榴缓存/可配置逐出/缓冲区替换策略

是否计划了其他关于最大规模驱逐的替代策略？我需要一个MRU算法，这样系统就可以从缓存中获益。系统将记录以块的形式存储在磁盘上或内存中的缓存页面中，而页面/记录不是群集的（更新后可能不会以预排序的形式存储）。本例中的记录是树结构中的节点

系统按升序分配记录ID（也就是说，首先它们是按前序分配的），并将记录存储在ID递增的页面中（0、1、2…）。然而，在更新之后，如果需要按预定顺序遍历记录/节点，则可能会读取带有记录1、2、3、4、5、6、7、8、9、10的页面。。。但是节点已经插入到节点6和7之间（例如，节点11有一个大的子树）。在这种情况下，缓存只有在保留第一页时才有用（其中存储记录1,2…，10，如果缓存大小为1，并且在节点11上扎根的子树属于另一个页面。则必须获取第一个页面两次。对于其他树遍历方法，情况类似，MRU比LRU更有用，但可能存在其他更适合的聪明算法。可能是aspect具有自校正功能

很抱歉对我的用例（一个版本化数据存储系统）进行了冗长的描述，但我希望它是一个有效的用例。因此，如果基于大小的逐出是可配置的，那就太好了，因为在某些情况下，LRU可能也很有意义（但可能不适用于树遍历）

---

编辑：我甚至不需要并发支持，只要我一次只允许一个写事务（因为Guava将条目分割成不同的段，这样它就不使用全局LRU算法）.

设计理念是不保证基于大小的逐出策略决定逐出哪个元素的算法行为。这提供了向更高级的逐出策略发展的灵活性，例如，并改进缓存的设计，例如，不分段。合同是缓存将尝试智能地选择e满足大多数用例的受害者

imho，当前的实现已经过于复杂，我不赞成提供许多调整算法的切换。这会让一小部分用户对api感到困惑，限制进行设计改进的能力，并将复杂性增加到可容忍的水平之外。最好使用您自己的解决方案当番石榴的多面手方法不合适时，最适合你的问题

---

正确的答案取决于您的用例。如果您不需要高并发性，那么有许多明显的答案。但是，如果您需要，那么使用MRU策略可能是最不痛苦的。自定义实现的中间地带，例如，可能使用简化版本的缓冲策略，可能是最容易封装在l中的arge代码库。

我目前甚至不确定这是否是一个好主意。可能是按照顺序读取第1、2、3和4页（而缓存/缓冲区的最大大小为3）。然后获取第4页将退出第3页，但可能必须再次读取，因为在第3页的节点之间插入了子树（子树位于第4页）。因此，前序遍历必须先读取1、2、3和4，然后再读取3，因此LRU会更好；-）我想这是一种进退两难的局面。将这样的节点聚集在一起最好，但再次只针对一种访问模式（前、后、级别、顺序…）。听起来你想要像LIRS一样的扫描常驻政策。谢谢，那么我肯定会坚持使用番石榴缓存，因为我正在广泛使用图书馆。希望LIRS将来会实施：-）或者…我想（现在知道；-）Charles Fry已经实施了LirsMap。