java - Guava 缓存/可配置的驱逐/缓冲区替换策略

Question

是否计划了关于最大尺寸驱逐的其他更换策略？我需要一个 MRU 算法，这样系统才能从缓存中受益。系统将记录存储在磁盘上的块中或内存中的缓存页面中，而页面/记录没有聚集(更新后可能没有按预序存储)。在我的情况下，记录是树结构中的节点。

系统按升序分配记录 ID(即首先它们是预序的)，并且还将记录存储在具有递增 ID(0、1、2...)的页面中。然而，在更新之后，如果记录/节点例如需要按预先顺序遍历，则可能是读取一个页面，其中记录为 1、2、3、4、5、6、7、8、9、10……但是节点已插入节点 6 和节点 7 之间(例如节点 11 具有大子树)。在这种情况下，缓存仅在保留第一页(如果缓存大小为 1 并且以节点 11 为根的子树属于另一页的情况下存储记录 1,2...,10 的记录)时才有用。那么第一页必须是取两次。其他树遍历方法的情况类似，MRU 比 LRU 更有用，但也许存在其他更适合的聪明算法。可能是自调整的一个方面。

很抱歉我的用例(版本化数据存储系统)的详细描述，但我希望它是一个有效的用例。因此，如果基于大小的驱逐是可配置的，那将会很好，因为在某些情况下，LRU 也可能完全有意义(但可能不适用于树遍历)。

编辑:我可能甚至不需要并发支持，只要我一次只允许一个写事务(因为 Guava 将条目拆分为不同的段，因此它不使用全局 LRU 算法)。

Answer 1

设计理念是不对基于大小的驱逐策略决定驱逐哪个元素的算法行为做出保证。这为演变为更高级的驱逐策略提供了灵活性，例如 LIRS ，并改进缓存的设计，例如不被分割。契约是缓存将尝试智能地选择满足大多数用例的受害者。

目前的实现已经过于复杂了，恕我直言，我不赞成提供大量的切换来调整算法。这将使 api 对一小部分用户造成混淆，限制进行设计改进的能力，并将复杂性增加到超出可容忍的水平。当 Guava 的通才方法不合适时，最好推出最适合您的问题的自己的解决方案。

正确答案取决于您的用例。如果您不需要高并发，那么有很多显而易见的答案。但是，如果你这样做，那么 fork ConcurrentLinkedHashMap使用 MRU 策略可能是最不痛苦的。自定义实现的中间地带，例如也许使用缓冲策略的简化版本，可能最容易封装在大型代码库中。