In der Guava-Bibliothek bin ich verwirrt darüber, warum Cache.asMap() stimmt nicht mit Cache.size() , es sei denn, Cache.cleanUp() wird aufgerufen.
Also meine Frage: Ist es ein Fehler, dass Cache.asMap() nicht konsistent zu Cache.size() ist?
Obwohl ich feststelle, dass das Javadoc von Cache.size() ist:
Ich kann nur vermuten, dass es sich um eine konkurrierende Umgebung handelt.
Und was macht Cache.cleanUp() genau?
Guavas Cache ist auf Lock-Amortisation ausgelegt und die Methode cleanUp zwingt den Cache, einen konsistenten Zustand zu erreichen. Die Map.size() -Methode ist eine Annäherung, kann jedoch Einträge zählen, die aufgrund einer Verfalls- oder Referenzräumung auf Entfernung warten. Die Sichtbarkeit der Näherungswerte in Guavas Cache ist für eine Anwendung selten von großem Interesse, da sie einen Cache als vorübergehenden Datenspeicher betrachtet. Die unterschiedlichen Erwartungen eines Caches aus einer Map führten zur asMap -Methode, damit der Cache als Karte angezeigt werden kann. Entwickler werden jedoch davon abgehalten, dies so wahrzunehmen.
Die Implementierungsdetails des Caches wurden in den Folien der StrangleLoop 2011-Konferenz behandelt. Das Design-Dokument von ConcurrentLinkedHashMap , aus dem der Cache von Guava stammt, könnte ebenfalls von Interesse sein, beschreibt es jedoch ein etwas anderer Ansatz.
Ben gab eine gute High-Level-Antwort. Die Low-Level-Antwort lautet:
asMap() views haben den Luxus, jedes Element im Cache zu durchlaufen, und können daher ungültige Einträge überspringen, die gerade aufzuräumen sind. Auf der anderen Seite wird erwartet, dass size() eine schnelle Operation ist, und es wäre albern, den gesamten Cache zu durchlaufen, nur um eine genauere Größenschätzung zu erhalten.
Die CacheBuilder Javadocs werden angezeigt mehr Details bezüglich der Bereinigung, die in verschiedenen Situationen passieren muss (wie zum Beispiel expireAfterWrite , in Ihrem Fall).
Tags und Links java caching concurrency guava