Por favor, no diga EHCache o OSCache, etc. Suponga a los fines de esta pregunta que quiero implementar el mío usando solo el SDK (aprender haciendo). Dado que el caché se usará en un entorno multiproceso, ¿qué estructuras de datos usaría? Ya he implementado uno usando LinkedHashMap y Collections # synchronizedMap , pero tengo curiosidad por saber si alguna de las nuevas colecciones concurrentes serían mejores candidatos.
ACTUALIZACIÓN: Estaba leyendo lo último de Yegge cuando encontré esta pepita:
Si necesita acceso de tiempo constante y desea mantener el orden de inserción, no puede hacerlo mejor que LinkedHashMap, una estructura de datos realmente maravillosa. La única forma en que podría ser más maravilloso es si hubiera una versión concurrente. Pero Ay.
Estaba pensando casi exactamente lo mismo antes de comenzar con la implementación LinkedHashMap
+ Collections#synchronizedMap
que mencioné anteriormente. Es bueno saber que no había pasado por alto algo.
Según las respuestas hasta ahora, parece que mi mejor apuesta para una LRU altamente concurrente sería extender ConcurrentHashMap usando algo de la misma lógica que LinkedHashMap
usa.
fuente
O(1)
versión requerida: stackoverflow.com/questions/23772102/…Respuestas:
Me gustan muchas de estas sugerencias, pero por ahora creo que me quedaré con
LinkedHashMap
+Collections.synchronizedMap
. Si yo vuelva a visitar en el futuro, probablemente voy a trabajar en la ampliaciónConcurrentHashMap
de la misma maneraLinkedHashMap
se extiendeHashMap
.ACTUALIZAR:
A pedido, aquí está la esencia de mi implementación actual.
fuente
LinkedHashMap
respaldan explícitamente este método para crear una implementación de LRU.Si volviera a hacer esto desde cero hoy, usaría Guava's
CacheBuilder
.fuente
Esta es la segunda ronda.
La primera ronda fue lo que se me ocurrió, luego releí los comentarios con el dominio un poco más arraigado en mi cabeza.
Así que aquí está la versión más simple con una prueba unitaria que muestra que funciona según algunas otras versiones.
Primero la versión no concurrente:
La verdadera bandera rastreará el acceso de gets y put. Ver JavaDocs. RemoveEdelstEntry sin el indicador verdadero para el constructor simplemente implementaría un caché FIFO (vea las notas a continuación en FIFO y removeEldestEntry).
Aquí está la prueba que demuestra que funciona como un caché LRU:
Ahora para la versión concurrente ...
paquete org.boon.cache;
Puedes ver por qué cubro primero la versión no concurrente. Lo anterior intenta crear algunas franjas para reducir la contención de bloqueo. Entonces usamos la clave y luego busca esa clave para encontrar el caché real. Esto hace que el tamaño límite sea más una sugerencia / conjetura aproximada dentro de una buena cantidad de error, dependiendo de qué tan bien esté el algoritmo hash de claves.
Aquí está la prueba para mostrar que la versión concurrente probablemente funciona. :) (Prueba bajo fuego sería la forma real).
Esta es la última publicación. La primera publicación que eliminé, ya que era un LFU, no un caché de LRU.
Pensé en darle otra oportunidad. Estaba tratando de encontrar la versión más simple de un caché LRU usando el JDK estándar sin demasiada implementación.
Esto es lo que se me ocurrió. Mi primer intento fue un poco desastroso cuando implementé un LFU en lugar de un LRU, y luego agregué FIFO y el soporte de LRU ... y luego me di cuenta de que se estaba convirtiendo en un monstruo. Luego comencé a hablar con mi amigo John, que apenas estaba interesado, y luego le describí a fondo cómo implementé un LFU, LRU y FIFO y cómo podía cambiarlo con un simple argumento ENUM, y luego me di cuenta de que todo lo que realmente quería fue un simple LRU. Así que ignóreme la publicación anterior y avíseme si desea ver un caché LRU / LFU / FIFO que se puede cambiar a través de una enumeración ... ¿no? Ok .. aquí va.
La LRU más simple posible usando solo el JDK. Implementé tanto una versión concurrente como una versión no concurrente.
Creé una interfaz común (es minimalismo, por lo que probablemente falten algunas características que le gustaría, pero funciona para mis casos de uso, pero si desea ver la función XYZ, hágamelo saber ... vivo para escribir código). .
Te preguntarás qué es getSilent . Lo uso para probar. getSilent no cambia la puntuación LRU de un elemento.
Primero el no concurrente ...
El queue.removeFirstOccurrence es una operación potencialmente costoso si usted tiene un gran caché. Se podría tomar LinkedList como ejemplo y agregar un mapa hash de búsqueda inversa de elemento a nodo para hacer que las operaciones de eliminación sean MÁS RÁPIDAS y más consistentes. También comencé, pero luego me di cuenta de que no lo necesitaba. Pero tal vez...
Cuando se llama a put , la clave se agrega a la cola. Cuando se llama a get , la clave se elimina y se vuelve a agregar a la parte superior de la cola.
Si su caché es pequeña y la construcción de un artículo es costosa, entonces esta debería ser una buena caché. Si su caché es realmente grande, entonces la búsqueda lineal podría ser un cuello de botella, especialmente si no tiene áreas calientes de caché. Cuanto más intensos sean los puntos calientes, más rápida será la búsqueda lineal, ya que los elementos calientes siempre están en la parte superior de la búsqueda lineal. De todos modos ... lo que se necesita para que esto vaya más rápido es escribir otra LinkedList que tenga una operación de eliminación que tenga un elemento inverso a la búsqueda de nodo para eliminar, luego eliminar sería tan rápido como eliminar una clave de un mapa hash.
Si tiene un caché de menos de 1,000 elementos, esto debería funcionar bien.
Aquí hay una prueba simple para mostrar sus operaciones en acción.
El último caché de LRU tenía un solo subproceso, y no lo envuelva en nada sincronizado ...
Aquí hay una puñalada en una versión concurrente.
Las principales diferencias son el uso de ConcurrentHashMap en lugar de HashMap y el uso de Lock (podría haber salido con sincronizado, pero ...).
No lo he probado bajo fuego, pero parece un simple caché LRU que podría funcionar en el 80% de los casos de uso en los que necesita un mapa LRU simple.
Agradezco sus comentarios, excepto por qué no utiliza la biblioteca a, b o c. La razón por la que no siempre uso una biblioteca es porque no siempre quiero que cada archivo war tenga 80 MB, y escribo bibliotecas, por lo que tiendo a hacer que las bibliotecas se puedan conectar con una solución lo suficientemente buena y alguien pueda conectar -en otro proveedor de caché si lo desean. :) Nunca sé cuándo alguien podría necesitar guayaba o ehcache u otra cosa que no quiero incluir, pero si hago que el almacenamiento en caché sea conectable, tampoco los excluiré.
La reducción de dependencias tiene su propia recompensa. Me encanta recibir comentarios sobre cómo hacer esto aún más simple o más rápido o ambos.
Además, si alguien sabe de un listo para ir ...
Ok ... sé lo que estás pensando ... ¿Por qué no solo usa la entrada removeEldest de LinkedHashMap, y bueno debería pero ... pero ... pero ... Eso sería un FIFO no un LRU y estábamos tratando de implementar una LRU.
Esta prueba falla para el código anterior ...
Así que aquí hay un caché FIFO rápido y sucio usando removeEldestEntry.
FIFOs son rápidos. No busques alrededor. Podrías hacer frente a un FIFO frente a una LRU y eso manejaría muy bien la mayoría de las entradas activas. Una LRU mejor necesitará ese elemento inverso a la función Nodo.
De todos modos ... ahora que escribí un código, déjame revisar las otras respuestas y ver lo que me perdí ... la primera vez que las escaneé.
fuente
LinkedHashMap
es O (1), pero requiere sincronización. No es necesario reinventar la rueda allí.2 opciones para aumentar la concurrencia:
1. Crear múltiples
LinkedHashMap
, y el hash en ellos: ejemplo:LinkedHashMap[4], index 0, 1, 2, 3
. En la tecla dokey%4
(ubinary OR
on[key, 3]
) para elegir qué mapa hacer un put / get / remove.2. Podrías hacer un 'casi' LRU extendiéndote
ConcurrentHashMap
y teniendo un mapa hash vinculado como una estructura en cada una de las regiones dentro de él. El bloqueo se produciría de forma más granular que unLinkedHashMap
sincronizado. En unoput
oputIfAbsent
solo se necesita un bloqueo en la cabeza y la cola de la lista (por región). Al eliminar u obtener, toda la región debe estar bloqueada. Tengo curiosidad por saber si las listas enlazadas de Atomic de algún tipo podrían ayudar aquí, probablemente para el encabezado de la lista. Quizás por más.La estructura no mantendría el orden total, sino solo el orden por región. Siempre que el número de entradas sea mucho mayor que el número de regiones, esto es lo suficientemente bueno para la mayoría de las memorias caché. Cada región tendrá que tener su propio recuento de entradas, esto se utilizaría en lugar del recuento global para el desencadenante de desalojo. El número predeterminado de regiones en a
ConcurrentHashMap
es 16, que es suficiente para la mayoría de los servidores de hoy.sería más fácil de escribir y más rápido con una concurrencia moderada.
sería más difícil de escribir pero escala mucho mejor con una concurrencia muy alta. Sería más lento para el acceso normal (al igual que
ConcurrentHashMap
es más lento queHashMap
donde no hay concurrencia)fuente
Hay dos implementaciones de código abierto.
Apache Solr tiene ConcurrentLRUCache: https://lucene.apache.org/solr/3_6_1/org/apache/solr/util/ConcurrentLRUCache.html
Hay un proyecto de código abierto para un ConcurrentLinkedHashMap: http://code.google.com/p/concurrentlinkedhashmap/
fuente
ConcurrentLinkedHashMap
es interesante. Afirma haber sido rodadoMapMaker
desde Guava, pero no lo vi en los documentos. ¿Alguna idea de lo que está pasando con ese esfuerzo?Consideraría usar java.util.concurrent.PriorityBlockingQueue , con prioridad determinada por un contador "numberOfUses" en cada elemento. Sería muy, muy cuidadoso para obtener toda mi sincronización correcta, ya que el contador "numberOfUses" implica que el elemento no puede ser inmutable.
El objeto del elemento sería un contenedor para los objetos en el caché:
fuente
Espero que esto ayude .
fuente
La caché de LRU se puede implementar usando un ConcurrentLinkedQueue y un ConcurrentHashMap que también se puede usar en un escenario de subprocesos múltiples. La cabeza de la cola es ese elemento que ha estado en la cola por más tiempo. La cola de la cola es ese elemento que ha estado en la cola el menor tiempo. Cuando existe un elemento en el Mapa, podemos eliminarlo de LinkedQueue e insertarlo en la cola.
fuente
put
.Aquí está mi implementación para LRU. He usado PriorityQueue, que básicamente funciona como FIFO y no es seguro. Comparador usado basado en la creación del tiempo de página y basado en la realización del pedido de las páginas por el tiempo usado menos recientemente.
Páginas para consideración: 2, 1, 0, 2, 8, 2, 4
La página agregada al caché es: 2 La
página agregada al caché es: 1 La
página agregada al caché es: 0 La
página: 2 ya existe en el caché. Último tiempo de acceso actualizado
Fallo de página, PÁGINA: 1, Reemplazado con PÁGINA: 8 La
página agregada en la memoria caché es: 8
Página: 2 ya existe en la memoria caché. Último tiempo de acceso actualizado
Fallo de página, PÁGINA: 0, Reemplazado con PÁGINA: 4 La
página agregada en la caché es: 4
SALIDA
LRUCache Pages
-------------
PageName: 8, PageCreationTime: 1365957019974
PageName: 2, PageCreationTime: 1365957020074
PageName: 4, PageCreationTime: 1365957020174
Ingresa el código aquí
fuente
Aquí está mi implementación probada de caché LRU simultánea de mejor rendimiento sin ningún bloque sincronizado:
}
fuente
Esta es la caché LRU que uso, que encapsula un LinkedHashMap y maneja la concurrencia con un simple bloqueo de sincronización que protege los puntos jugosos. "Toca" los elementos a medida que se usan para que se conviertan nuevamente en el elemento "más fresco", de modo que en realidad es LRU. También tuve el requisito de que mis elementos tuvieran una vida útil mínima, lo que también se puede considerar como el "tiempo de inactividad máximo" permitido, entonces está listo para ser desalojado.
Sin embargo, estoy de acuerdo con la conclusión de Hank y la respuesta aceptada: si comenzara esto de nuevo hoy, verificaría Guava
CacheBuilder
.fuente
Bueno, para un caché, generalmente buscará algún dato a través de un objeto proxy (una URL, cadena ...), por lo que en cuanto a la interfaz, querrá un mapa. pero para expulsar las cosas quieres una cola como estructura. Internamente, mantendría dos estructuras de datos, una Cola de prioridad y un HashMap. Heres una implementación que debería ser capaz de hacer todo en tiempo O (1).
Aquí hay una clase que preparé bastante rápido:
Así es como funciona. Las claves se almacenan en una lista vinculada con las claves más antiguas al principio de la lista (las claves nuevas van al reverso), de modo que cuando necesite 'expulsar' algo, simplemente salga del frente de la cola y luego use la clave para eliminar el valor del mapa. Cuando se hace referencia a un elemento, toma el ValueHolder del mapa y luego usa la variable de ubicación para quitar la clave de su ubicación actual en la cola y luego la coloca en la parte posterior de la cola (ahora es la más recientemente utilizada). Agregar cosas es más o menos lo mismo.
Estoy seguro de que hay un montón de errores aquí y no he implementado ninguna sincronización. pero esta clase proporcionará O (1) agregando a la caché, O (1) eliminación de elementos antiguos y O (1) recuperación de elementos de la caché. Incluso una sincronización trivial (solo sincronice todos los métodos públicos) aún tendría poca contención de bloqueo debido al tiempo de ejecución. Si alguien tiene algún truco inteligente de sincronización, estaría muy interesado. Además, estoy seguro de que hay algunas optimizaciones adicionales que podría implementar utilizando la variable maxsize con respecto al mapa.
fuente
LinkedHashMap
+Collections.synchronizedMap()
?Echa un vistazo a ConcurrentSkipListMap . Debería darle tiempo de registro (n) para probar y eliminar un elemento si ya está contenido en el caché, y tiempo constante para volver a agregarlo.
Solo necesitará un contador, etc. y un elemento de envoltura para forzar el pedido de la orden LRU y asegurarse de que las cosas recientes se descarten cuando el caché esté lleno.
fuente
ConcurrentSkipListMap
Proporcionaría algún beneficio de facilidad de implementaciónConcurrentHashMap
, o es simplemente un caso de evitar casos patológicos?ConcurrentSkipListMap
implementación, ¿crearía una nueva implementación de laMap
interfaz que delegueConcurrentSkipListMap
y realice algún tipo de ajuste para que los tipos de claves arbitrarias se envuelvan en un tipo que se ordene fácilmente en función del último acceso?Aquí está mi breve implementación, ¡critíquela o mejore!
fuente
Aquí está mi propia implementación de este problema
simplelrucache proporciona almacenamiento en caché LRU seguro, muy simple y no distribuido con soporte TTL. Proporciona dos implementaciones:
Puede encontrarlo aquí: http://code.google.com/p/simplelrucache/
fuente
La mejor manera de lograrlo es usar un LinkedHashMap que mantenga el orden de inserción de los elementos. El siguiente es un código de muestra:
}
fuente
Estoy buscando un mejor caché LRU usando código Java. ¿Es posible que comparta su código de caché Java LRU usando
LinkedHashMap
yCollections#synchronizedMap
? Actualmente estoy usandoLRUMap implements Map
y el código funciona bien, pero estoy haciendoArrayIndexOutofBoundException
pruebas de carga con 500 usuarios en el siguiente método. El método mueve el objeto reciente al frente de la cola.get(Object key)
y elput(Object key, Object value)
método llama almoveToFront
método anterior .fuente
Quería agregar un comentario a la respuesta dada por Hank, pero de alguna manera no puedo hacerlo, trátelo como un comentario
LinkedHashMap también mantiene el orden de acceso en función del parámetro pasado en su constructor. Mantiene una lista doblemente alineada para mantener el orden (Ver LinkedHashMap.Entry)
@Pacerier es correcto que LinkedHashMap mantenga el mismo orden durante la iteración si el elemento se agrega nuevamente, pero eso es solo en el caso del modo de orden de inserción.
Esto es lo que encontré en los documentos de Java del objeto LinkedHashMap.Entry
Este método se encarga de mover el elemento al que se accedió recientemente al final de la lista. Así que, en general, LinkedHashMap es la mejor estructura de datos para implementar LRUCache.
fuente
Otro pensamiento e incluso una implementación simple usando la colección de Java LinkedHashMap.
LinkedHashMap proporcionó el método removeEldestEntry y que se puede anular de la manera mencionada en el ejemplo. Por defecto, la implementación de esta estructura de colección es falsa. Si su verdadero y tamaño de esta estructura supera la capacidad inicial, se eliminarán los elementos más antiguos o más antiguos.
Podemos tener un pageno y el contenido de la página en mi caso pageno es entero y el contenido de la página he mantenido la cadena de valores del número de página.
El resultado de la ejecución del código anterior es el siguiente:
fuente
Siguiendo el concepto @sanjanab (pero después de las correcciones), hice mi versión de LRUCache proporcionando también al Consumidor que permite hacer algo con los elementos eliminados si es necesario.
fuente
Android ofrece una implementación de un caché LRU . El código es limpio y directo.
fuente