LRU緩存對Trie數據結構如何起作用？

Question

假設我有一個trie / prefix trie，總共限制為10個節點。 我限制為10個節點以模擬超出的內存。 （如果無法將整個樹加載到內存中，則總共-磁盤上存儲了10個節點。

現在，我在Trie中插入一個新字符串，這將導致樹超過10個節點的限制，因此現在是時候讓LRU緩存從Trie中退出最近訪問最少的節點了。

假設樹包含單詞hello，help，hi，並且LRU節點為“ h”。 這意味着我需要從特里刪除“ h”，在這種情況下，這將刪除整個樹。 我的困惑在於還更新了緩存本身以刪除所有子項。 在這種情況下如何運作？

我假設高速緩存具有“ h”，“ he”，“ hel”，“ help”等節點。如果刪除“ h”節點，我假設需要刪除高速緩存中以“ h”為前綴的所有內容？ 我的整個假設似乎效率很低。

Answer 1

在談論高速緩存時，要記住的一件事是，它是一個冗余的數據結構，其唯一目的是加快數據的獲取速度。
因此，當從高速緩存中逐出一條數據時，它對使用該數據的程序沒有任何影響（執行速度除外），因為它隨后將從主存儲器中獲取。 因此，無論如何，您的特里樹都將具有完全相同的行為，而不管它的哪一部分位於緩存中。

這非常重要，因為它允許我們使用高級語言（例如Java）進行編碼，而無需關心處理器實現的緩存的替換策略。 如果不是這種情況，那將是一場噩夢，因為我們必須考慮到處理器中實施的所有現有（以及將來的？）更換政策。 甚至沒有提到這些策略不像LRU那樣簡單（存在緩存集，將緩存分為“行”，並且它們的行為也與它們的物理結構密切相關），並且放置了一部分數據高速緩存中的地址取決於其在主存儲器中的地址，對於每個代碼執行而言，地址不一定相同。

簡而言之，您提到的兩件事（java中的trie節點和LRU緩存策略）相距太遠（一件事是非常非常低級的編程，另一件事是非常高級的編程）。 這就是為什么我們很少（如果有的話）很少考慮它們的相互作用。
如果您使用Java實現Trie，則您的工作是確保它在所有情況下均能正常工作，並且設計合理，因此維護會更容易（可能），可讀性強，以便其他程序員有一天可以使用它。 最終，如果它仍然運行太慢，您可以嘗試對其進行優化（確定瓶頸所在之后，再也沒有）。
但是，如果要將特里鏈接到緩存命中/未命中以及替換策略，則必須讀取字節碼（由JVM完成）的實現翻譯。

PS：在您的文章中，您談到模擬正在執行的內存。 程序沒有這樣的東西。 當緩存已滿時，我們將填充主內存。 當主內存已滿時，操作系統通常會保留一部分硬盤驅動器以發揮主內存的作用（我們稱其為交換，當發生交換時，計算機的性能與凍結一樣好）。 當交換已滿時，程序崩潰。 他們全部。
在程序的“思想”中，操作系統為它提供了絕對巨大的內存量（這是虛擬的，但對於程序來說，它與真實的一樣好），永遠不會被填滿。 程序本身並不“知道”內存的管理方式以及剩余的內存量，原因有很多（安全性，請確保所有程序在資源中都有合理的份額……）