LRU LinkedHashMap que limita el tamaño según la memoria disponible

Question

Quiero crear un LinkedHashMap que limitará su tamaño en función de la memoria disponible (es decir, cuando freeMemory + (maxMemory - allocatedMemory) se encuentre por debajo de un determinado umbral). Esto se usará como una forma de caché, probablemente utilizando el "uso menos reciente" como estrategia de almacenamiento en caché.

Mi preocupación es que la memoria asignada también incluye (supongo) los datos recolectados sin basura, y así sobreestimar la cantidad de memoria utilizada. Me preocupan las consecuencias involuntarias que esto podría tener.

Por ejemplo, LinkedHashMap puede seguir eliminando elementos porque cree que no hay suficiente memoria libre, pero la memoria libre no aumenta porque estos elementos eliminados no se recogen de forma inmediata.

¿Alguien tiene alguna experiencia con este tipo de cosas? ¿Está justificada mi preocupación? Si es así, ¿alguien puede sugerir un buen enfoque?

Debo agregar que también quiero ser capaz de "bloquear" la memoria caché, básicamente diciendo "ok, a partir de ahora no elimine nada debido a problemas de uso de memoria".

Answer 1

Sé que soy parcial, pero realmente tengo que recomendar encarecidamente nuestro MapMaker para esto. Use la función softKeys() o softValues ​​(), dependiendo de si es la recopilación de GC de la clave o del valor que describe más acertadamente cuando se puede limpiar una entrada.

Answer 2

Los cachés tienden a ser problemáticos. IIRC, hay un SoftCache en Sun's JRE que ha tenido muchos problemas.

De todos modos, lo más simple es usar SoftReference s en el mapa. Esto debería funcionar bien siempre que la sobrecarga de SoftReference más Map.Entry sea significativamente menor que los datos en caché.

También puede, como WeakHashMap, usar un ReferenceQueue y sondearlo o tener un bloqueo de hilo en él (un hilo por instancia, desafortunadamente). Tenga cuidado con los problemas de sincronización.

"Bloqueando" el mapa, es probable que desee evitarlo si es necesario. Debería mantener fuertes referencias a todos los datos (y desalojar si no es nulo). Eso va a ser feo

Answer 3

Sugeriría usar algo como Ehcache en lugar de reinventar un sistema de almacenamiento en caché. Es súper simple de usar, muy configurable y funciona muy bien.

Answer 4

Como dijo matt b, algo como Ehcache o JbossCache es un buen primer paso.

Si desea algo ligero y en proceso, consulte las colecciones de google. Por ejemplo, puede usar MapMaker (http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?com/google/common/collect/BiMap.html) para hacer un mapa con claves y valores Suaves/Débiles, por lo que solo almacenaría en caché los elementos para los que tiene espacio (aunque no obtendría LRU).

Answer 5

que tenía la misma necesidad en el pasado y así es como he implementado mi caché:

• hay un gestor de memoria caché, que tiene un mínimo y un límite máximo de memoria (máx limitarlo importa de todos modos)
• cada caché registrado tiene los siguientes parámetros (importantes): capacidad máxima (la mayor parte del tiempo que tiene un límite más alto, usted no quiere ir contener más de X material) el uso de memoria & ciento
• que utilizo un LinkedHashMap y un ReentrantReadWriteLock para proteger el caché.
• cada X pone Calculo el consumo medio de memoria por entrada y activa el desalojo (asincrónico) si el límite de memoria calculado> permite el límite de memoria.
• Por supuesto, el cálculo de la memoria no muestra realmente el consumo de memoria real, pero al comparar la memoria calculada con el valor real (usando un generador de perfiles) me parece que está lo suficientemente cerca.

Estaba planeando poner también un protector adicional en el caché, para desalojar en caso de que las puts sean más rápidas que los desalojos basados ​​en memoria, pero hasta ahora no he encontrado la necesidad de hacerlo.