番石榴緩存/可配置逐出/緩存替換策略

Question

是否計劃了有關最大規模逐出的其他替換策略？我需要一個MRU算法，以便系統從緩存中受益。系統將數據以塊的形式存儲在磁盤上或緩存頁面的內存中，而頁面/記錄未被聚集（可能不會在更新後以預先存儲的形式存儲）。在我的情況下，記錄是樹狀結構中的節點。

系統按升序分配記錄標識（即首先它們處於預訂狀態），並將記錄存儲在帶有遞增ID（0,1,2 ...）的頁面中。然而，在更新之後，如果例如記錄/節點需要以預先遍歷的方式進行遍歷，那麼可能是頁面被記錄1,2,3,4,5,6,7,8,9,10 ...讀取，但是已經在節點6和7之間插入節點（例如具有大子樹的節點11）。在這種情況下，緩存僅在保留第一頁（其中存儲記錄1,2 ...，如果緩存大小爲1且以節點11爲根的子樹屬於另一頁時爲10）時有用，則第一頁必須是取而代之，其他樹遍歷方法的情況也是如此，MRU比LRU更有用，但也許存在其他更適合的聰明算法，可能是自調整的一個方面。對於我的用例（一個版本化的數據存儲系統）的長篇描述，但我希望它是一個有效的用例。因此，如果基於大小的驅逐是可配置的，在某些情況下，LRU完全有意義但可能不適用於樹遍歷）

編輯：我可能甚至不需要併發性支持，只要我一次只允許一次寫入事務（因爲Guava將條目分割成不同的段，因此它不使用全局LRU算法）。

Answer 1

設計理念是不對基於大小的驅逐策略決定驅逐哪個元素的算法行爲做出保證。這提供了靈活性以演變爲更高級的驅逐策略，例如LIRS，並且改進了高速緩存的設計，例如，不被分割。合同是緩存將嘗試智能地選擇一個滿足大部分用例的受害者。

目前的實現已經過於複雜了，我不會贊成提供大量的調整算法的切換。這會讓api讓一小部分用戶感到困惑，限制改進設計的能力，並增加超出可接受水平的複雜性。當番石榴的多面手方法不合適時，它最好推出自己最能解決問題的解決方案。

正確答案取決於您的使用情況。如果你不需要很高的併發性，那麼有很多明顯的答案。不過，如果你這樣做，那麼分支ConcurrentLinkedHashMap使用MRU策略可能是最不痛苦的。自定義實現的中間地帶，例如也許使用緩衝策略的簡化版本，可能是最容易封裝在大型代碼庫中的。