2010-11-22 13 views
28

El JDK se envía con CopyOnWrite* implementaciones para Set y List, pero ninguna para Map y a menudo he lamentado este hecho. Sé que hay otras implementaciones de colecciones que los tienen, pero sería bueno si se envía como estándar. Parece una omisión obvia y me pregunto si hubo una buena razón para ello. Alguien tiene alguna idea de por qué esto fue omitido?¿Por qué Java no se envía con un CopyOnWriteMap?

+2

Mucha gente asume que java.util.Map es una colección, pero no lo es. Esto no está directamente relacionado con tu pregunta, pero algunas de las palabras me hicieron pensar que tal vez habías hecho esta suposición, así que pensé en señalarlo. – pkaeding

+1

De acuerdo, podría no implementar la interfaz de Colección y podríamos argumentar la semántica de qué colección verdadera. Pero el resultado de tales minucias no haría que CopyOnWriteMap fuera menos valioso o perdiera menos. – sgargan

+0

La iteración no es un caso de uso tan común para mapas como para otras colecciones. – msandiford

Respuesta

23

Supongo que esto depende de su caso de uso, pero ¿por qué necesitaría un CopyOnWriteMap cuando ya tiene un ConcurrentHashMap?

Para una tabla de búsqueda simple con muchos lectores y solo una o algunas actualizaciones, es una buena opción.

En comparación con una copia en la colección de escritura:

Leer concurrencia:

igual a una copia en la colección de escritura. Varios lectores pueden recuperar elementos del mapa al mismo tiempo en una forma sin cerradura.

Escribir concurrencia:

mejor concurrencia que la copia en colecciones de escritura que, básicamente, serializar actualizaciones (una actualización a la vez). Al usar un mapa hash simultáneo, tiene muchas posibilidades de realizar varias actualizaciones al mismo tiempo. Si sus claves hash están distribuidas uniformemente.

Si haces quieren tener el efecto de una copia en el mapa de escritura, siempre se puede inicializar una ConcurrentHashMap con un nivel de concurrencia 1.

+0

Los dos tipos de colecciones tienen diferentes propósitos. Una colección CopyOnWrite se leerá con mucha más frecuencia que la escrita y, en general, puede evitar la sobrecarga de bloquear las lecturas a expensas de la copia completa en cada escritura infrecuente.ConcurrentHashMap aún requerirá un bloqueo independientemente del valor de concurrencia. – sgargan

+0

Realmente lo que estoy buscando es una implementación de Mapas que se pueda usar de manera muy eficiente en una tabla de búsqueda. Se escribiría con muy poca frecuencia (en la mayoría de los casos, una vez) y se optimizaría para lecturas sin bloqueos. – sgargan

+1

Lea el javadoc para ConcurrentHashMap nuevamente, creo que se adapta a sus necesidades. Aquí hay dos fragmentos de él: "Una tabla hash que admite concurrencia completa de recuperación ..." y "... todas las operaciones son seguras para hilos, las operaciones de recuperación no implican bloqueo ...". Así que sí, es un ajuste perfecto para una tabla de búsqueda concurrente. –

0

La implementación más sencilla de un conjunto que suele ser el uso de una mapa subyacente. Incluso tienen un método Collections.newSetFromMap() [quizás solo desde 1.6].

Lo que deberían haber hecho es tener un CopyOnWriteMap y CopyOnWriteSet siendo equivalente a Collections.newSetFromMap (new CopyOnWriteMap()).

Pero como puede ver, el CopyOnWriteArraySet está respaldado por una matriz, no por un mapa. ¿Y no sería Collections.newSetFromMap (ConcurrentHashMap()) aceptable para su uso?

+0

OP pide un mapa, no un conjunto. – eckes

Cuestiones relacionadas