Ich habe die offizielle Android-Dokumentation für LRUCache ausgecheckt, die besagt: Jedes Mal, wenn auf einen Wert zugegriffen wird, wird er an den Anfang einer Warteschlange verschoben. Wenn ein Wert zu einem vollständigen Cache hinzugefügt wird, wird der Wert am Ende dieser Warteschlange entfernt und möglicherweise für die Garbage Collection geeignet. Ich nehme an, das ist die doppelt verknüpfte Liste, die von Linkedhashmap verwaltet wird, die vom Cache verwendet wird. Um dieses Verhalten zu überprüfen, habe ich den Quellcode für LruCache ausgecheckt und die Methode get (K key) überprüft. Außerdem ruft es die get-Methode von map auf, die den Wert von der zugrundeliegenden hashmap abruft und die recordAccess-Methode aufruft.
%Vor%Die recordAccess-Methode wiederum verschiebt den aufgerufenen Eintrag an das Ende der Liste, falls accessOrder auf true gesetzt ist (für mein Problem nehmen wir an, dass dies der Fall ist), sonst tut es nichts.
%Vor%Das klingt widersprüchlich zu der obigen Aussage, wo gesagt wird, dass das Element an den Anfang der Warteschlange verschoben wird. Stattdessen wird es zum letzten Element der Liste verschoben (mit head.before). Bestimmt vermisse ich hier etwas, jede Hilfe?
Sie verpassen nichts, nur Sie lesen LruCache documentation für LinkedHashMap . LinkedHashMap hat eine eigene Dokumentation, insbesondere zu accessOrder . (Das Gleiche gilt für Java-Dokumente ).
[... wenn accessOrder = true ...] Die Reihenfolge der Iteration ist die Reihenfolge, in der zuletzt auf die Einträge zugegriffen wurde, vom letzten bis zum letzten Zugriff (Zugriffsreihenfolge)
So LinkedHashMap setzt die zuletzt verwendeten Einträge am Ende und ist dokumentiert.
Praktisch LruCache beschreibt, wie ein solcher Cache theoretisch funktioniert, aber LinkedHashMap zeigt, wie man ihn implementiert, ohne separate Rückwärts-Iteratoren hinzuzufügen: indem man die letzten Elemente an das Ende setzt, trimming kann die bereits verfügbaren (Vorwärts- Bewegen) Iterator, um effizient auf alte Elemente zuzugreifen (und diese zu entfernen).
Obwohl ich hier und jetzt nicht sagen konnte, was mit removeEldestEntry . Vielleicht gab es das in der Vergangenheit nicht.
Aus dem Javadoc von LinkedHashMap :
Wenn der Konstruktor mit drei Argumenten verwendet wird und accessOrder als true angegeben ist, erfolgt die Iteration in der Reihenfolge, in der auf die Einträge zugegriffen wurde. Die Zugriffsreihenfolge wird von den Operationen put , get und putAll beeinflusst, nicht jedoch von den Operationen für die Sammlungsansichten.
Genau der Fall , das LruCache hat.
Mal sehen was recordAccess() macht:
Stattdessen wird es zum letzten Element der Liste verschoben (mit head.before).
Ich kann nicht sehen, wie Ihre Aussage gültig ist.
Tags und Links java android linkedhashmap android-lru-cache