java - threadlocalrandom - ¿Cuándo es útil un ConcurrentSkipListSet?

thread pool java

Question

Acabo de ver esta estructura de datos en la API de Java 6 y tengo curiosidad sobre cuándo sería un recurso útil. Estoy estudiando para el examen scjp y no lo veo cubierto en el libro de Kathy Sierra, a pesar de que he visto preguntas de exámenes simulados que lo mencionan.

Answer 1

ConcurrentSkipListMap fue un hallazgo fantástico cuando necesité implementar una capa de replicación para un caché nacional. Los aspectos del Mapa implementaron el caché y los aspectos subyacentes de la Lista me permitieron seguir el orden en que aparecieron los objetos en el caché. El aspecto de "omisión" de esa lista hacía que fuera eficiente eliminar un objeto de un lugar en la lista y alcanzarlo hasta el final cuando se reemplazó en la memoria caché.

Answer 2

Estos son útiles cuando necesita un conjunto al que se pueda acceder de manera segura mediante varios hilos simultáneamente. También proporciona un rendimiento decente al ser poco consistente: las inserciones se pueden realizar de forma segura mientras se itera a través del conjunto, pero no hay garantía de que su iterador vea esa inserción.

Answer 3

las listas de omisiones son listas ordenadas y eficientes de modificar con el rendimiento de log (n). en ese sentido, es como TreeSet. sin embargo, no hay ConcurrentTreeSet. lo que escuché es que la lista de omisiones es muy fácil de implementar, esa es probablemente la razón.

De todos modos, cuando necesite un conjunto simultáneo, ordenado y eficiente, puede usar ConcurrentSkipListSet

Answer 4

ConcurrentSkipListSet y ConcurrentSkipListMap son útiles cuando necesita un contenedor ordenado al que tendrán acceso múltiples subprocesos. Estos son esencialmente los equivalentes de TreeMap y TreeSet para el código concurrente.

La implementación de JDK 6 está basada en tablas Hash dinámicas de bloqueo de alto rendimiento y conjuntos basados en listas de Maged Michael en IBM, lo que demuestra que puede implementar muchas operaciones en listas de omisión de forma atómica mediante operaciones de comparación y canje (CAS) . No tienen bloqueos, por lo que no tiene que preocuparse por la sobrecarga de la synchronized (para la mayoría de las operaciones) cuando utiliza estas clases.

Actualmente, no existe una implementación de mapa / conjunto concurrente basada en un árbol rojo-negro en Java. Analicé un poco la literatura y encontré un couple papers que mostraban árboles de RB concurrentes que superaban a las listas de omisiones, pero muchas de estas pruebas se realizaron con memoria transaccional , que en este momento no es compatible con hardware en ninguna de las principales arquitecturas.

Asumo que los chicos de JDK fueron con una lista de omisión aquí porque la implementación era bien conocida y porque hacerlo sin bloqueos era simple y portátil (usando CAS). Si alguien quiere aclarar, por favor hazlo. Soy curioso.