Politica di sfratto della cache di Guava

Question

Ho provato la cache di guava di recente e sono rimasto sorpreso dalla politica di sfratto. Anche se la cache è chiaramente indicata come un lru nei documenti, ma non è de facto. Per me gli sfratti sembrano casuali come mostra il mio test. (il test è di aggiungere 100 etnie, ottenere 100 voci, potare 100 voci diverse, controllare l'ordine di sfratto) Non vorrei rilevare alcuni sfratti inaspettati in runtime. Potresti fornire qualche informazione sulla politica di sfratto per una cache di dimensioni limitate. Come posso forzare la rimozione della cache di guava come fa LHM?

Answer 1

Le cache di guava sono segmentate in concurrencyLevel tabelle hash diverse per consentire più letture e scritture simultanee. L'impostazione predefinita è concurrencyLevel 4. In sostanza, se il vostro maximumSize è impostato su 100, poi che in realtà solo i risultati in ognuno dei quattro segmenti ottenendo un maximumSize di 25. Questo è il motivo per cui gli stati maximumSize documentazione:

notare che il la cache può sfrattare una voce prima che questo limite venga superato. Man mano che la dimensione della cache si avvicina al massimo, la cache elude le voci che hanno meno probabilità di essere riutilizzate.

Quindi se per caso c'erano 30 voci inserite in un segmento particolare, 5 di queste voci verranno espulse.

L'unico modo per ottenere lo sfratto globale di cui è stato effettuato il minimo accesso per uno Cache è disattivare completamente la concorrenza impostando concurrencyLevel(1). Anche in questo caso, la documentazione non produce nessuna garanzia sull'ordine di sfratto degli elementi e non si deve dipendere da esso.