我正在瀏覽Guava Cache的示例,並想知道是否有某種方法可以防止某些條目在某些情況下被從緩存中逐出。防止條目從Guava Cache被逐出
就像一個應用程序正在使用某個條目一樣,它不太可能會讓它被驅逐!
的一種方式,我能想到的是使用CacheBuilder.weigher()
方法與基於大小的驅逐,因爲Javadoc中指出:
當條目的權重爲零,它不會被認爲是基於大小的逐出(儘管它仍然可能被其他方式驅逐)。
但權重是在開始時計算的,並且在高速緩存條目的生存期內是靜態的。所以,當一個條目不再被應用程序使用時,它的權重不能設置爲零。
有沒有其他有效的方法來實現這一目標?比如,一個方法將被Guava Cache調用,然後再驅逐一個特定的條目,不管它是否應該被驅逐!
另外,在MVP應用程序中緩存Presenter實例是個壞主意嗎?因爲我打算使用Guava Cache在我的應用程序中緩存Presenter實例!
您不應該在MVP中緩存演示者,因爲它們重量輕,應該流失率低。可能有緩存的應用程序數據,但組件本身應該很薄(例如,主持人調用緩存遠程數據的客戶端服務)。儘管緩存角度有解決方法,但它聽起來像走錯了路。 –
但是,由於演示者持有模型和視圖,因此應將演示者視爲MVP三元組。 MVP黑社會是否也被認爲是「輕量級」?另外,我緩存MVP三元組的目的不是爲了提高性能,而是爲了在我的Swing應用程序中支持「後退前進」導航。此外,如果任何啓動演示者的按鈕被按下多次,則加載現有的MVP實例。因此,每次點擊都不會創建新的MVP三元組!這是我的目的!我知道,這也可以通過其他方式完成,但緩存MVP對我來說似乎是一個好方法! – Akshat
三元組是輕量級的,其中Presenter在模型(啞數據)和視圖(啞數據用戶界面)之間進行協調。它有智慧,但沒有說明。非UI狀態的管理是對可能很複雜但封裝的客戶端服務的委託。通過將狀態編碼到導航中來管理歷史,例如,看看[瀏覽器歷史記錄是如何編碼的](https://en.wikipedia.org/wiki/Single-page_application#Browser_history)到URL中。後退/前進會創建新的三元組,以提供視圖。如果您決定使用緩存,那麼弱引用可能更適合。 –