Comment Guava expirme-t-il les entrées de son CacheBuilder?

Question

Je veux utiliser un CacheBuilder, comme recommandé ici :

Carte/cachet basée sur le temps en Java avec des clés expirantes

Cependant, je ne comprends pas quand Guava sait expirer les entrées.

Comment le fait Guava et quel coût de performance cela engendre-t-il ?

Answer 1

Membre de l'équipe Guava ici.

L'implémentation Guava Cache expire les entrées dans le cadre des opérations de maintenance normales, qui se produisent sur une base segmentaire lors des opérations d'écriture de cache et occasionnellement lors des opérations de lecture de cache. Les entrées ne sont généralement pas expirées exactement à leur heure d'expiration, simplement parce que Cache prend la décision délibérée de ne pas créer son propre thread de maintenance, mais plutôt de laisser l'utilisateur décider si une maintenance continue est nécessaire.

Je vais me concentrer sur expireAfterAccess, mais la procédure pour expireAfterWrite est presque identique. En termes de mécanique, lorsque vous spécifiez expireAfterAccess dans le CacheBuilder, chaque segment du cache maintient une file d'accès liée pour les entrées par ordre de moins récent accès à plus récent accès. Les entrées du cache sont en réalité elles-mêmes des nœuds dans la file d'accès, donc lorsqu'une entrée est accédée, elle se retire de sa position initiale dans la file d'accès et se déplace à la fin de la file.

Lorsque la maintenance du cache est effectuée, tout ce que le cache a à faire est d'expirer chaque entrée au début de la file jusqu'à ce qu'il trouve une entrée non expirée. Cela est simple et nécessite relativement peu de surcharge, et cela se produit dans le cadre de la maintenance normale du cache. (De plus, le cache limite délibérément la quantité de travail effectuée dans un seul nettoyage, minimisant les coûts pour chaque opération du cache.) En général, le coût de la maintenance du cache est principalement dominé par le coût de calcul des entrées réelles dans le cache.