60 votos

LinkedBlockingQueue vs ConcurrentLinkedQueue

Mi pregunta se refiere a esta cuestión preguntado antes. En situaciones donde yo estoy usando una cola para la comunicación entre el productor y el consumidor de los hilos de la gente suele recomendar el uso de LinkedBlockingQueue o ConcurrentLinkedQueue?

¿Cuáles son las ventajas / desventajas de la utilización de uno sobre el otro?

La principal diferencia que puedo ver desde una API es que la perspectiva de un LinkedBlockingQueue puede ser opcionalmente limitada.

65voto

Jon Skeet Puntos 692016

Para un productor/consumidor hilo, no estoy seguro de que ConcurrentLinkedQueue es aún una opción razonable - no aplicar BlockingQueue, que es el pilar fundamental de la interfaz de productor/consumidor de las colas de la OMI. Tendrías que llamar a poll(), esperar un poco si no había encontrado nada, y entonces encuesta de nuevo etc... dando lugar a retrasos cuando un nuevo elemento entra, y las ineficiencias cuando está vacía (debido a despertar innecesariamente desde duerme).

A partir de la documentación para el BlockingQueue:

BlockingQueue implementaciones están diseñados para ser utilizados principalmente para el productor-consumidor colas

Sé que no es estrictamente decir que sólo el bloqueo de las colas deben ser utilizados para el productor-consumidor colas, pero aún así...

21voto

Alexandru Nedelcu Puntos 3801

Esta pregunta merece una respuesta mejor.

Java ConcurrentLinkedQueue está basado en el famoso algoritmo de Artículo de M. Michael y Michael L. Scott para no-bloqueo libre de colas.

"No bloqueo" aquí como un término para un contendido de recursos (una cola) significa que, independientemente de lo que la plataforma del programador hace, como la interrupción de un hilo, o si el hilo en cuestión es simplemente demasiado lento, otros hilos compiten por el mismo recurso todavía será capaz de progresar. Si el bloqueo está involucrado por ejemplo, el hilo que mantiene el bloqueo podría ser interrumpida y todos los subprocesos en espera de que el bloqueo sería bloqueado. Intrínseca de cerraduras ( synchronized palabra clave) en Java también puede venir con una severa penalización de rendimiento - como cuando sesgada de bloqueo está involucrado y usted tiene la contención, o después de la VM se decide a "inflar" el bloqueo después de un giro período de gracia y el bloque de la pugna de los hilos ... es por eso que en muchos contextos (escenarios de bajo/medio de contención), haciendo compara y establece atómica referencias puede ser mucho más eficiente y esto es exactamente lo que muchos no-bloqueo de estructuras de datos que están haciendo.

Java ConcurrentLinkedQueue es no sólo la no-bloqueo, pero tiene la impresionante propiedad que el productor no se sostienen con el consumidor. En un solo productor / consumidor escenario (SPSC), esto significa que no habrá contención para hablar de. En un múltiplo de productores / consumidores escenario, el consumidor no tendrá que lidiar con los productores. Esta cola tiene contención cuando varios productores intentan offer(), pero que la concurrencia por definición. Se trata básicamente de un propósito general y eficiente sin bloqueo de cola.

Como para no ser BlockingQueue, así, el bloqueo de un hilo que esperar en una cola es una fenomenalmente forma terrible de diseño de sistemas concurrentes. No. Si usted no puede averiguar cómo usar un ConcurrentLinkedQueue en un consumidor/productor escenario, entonces solo tienes que cambiar a abstracciones de nivel más alto, como un buen actor marco.

3voto

dcernahoschi Puntos 7214

LinkedBlockingQueue está destinado para el uso de los casos cuando los consumidores y de los productores simultáneamente a consumir y producir. En este caso, por ejemplo, los consumidores podrían salir adelante de los productores y vacía la cola, por lo que la cola necesita bloque, mientras que los productores vienen con algo más de trabajo.

El ConcurrentLinkedQueue es útil, por ejemplo, cuando los productores de primer producir algo y terminar su trabajo mediante la colocación de la obra en la cola y sólo después de que los consumidores empieza a consumir, sabiendo que van a hacer cuando la cola está vacía. (aquí no hay simultaneidad entre productor-consumidor, sino sólo entre el productor-productor y consumidor-consumidor)

1voto

Rahul Puntos 51

Si la cola no es ampliable y contiene sólo un productor/consumidor hilo. Usted puede utilizar lockless cola (no es necesario para bloquear el acceso a los datos).

Rahul

0voto

Ovidiu Lupas Puntos 103

Otra solución (que no escala bien) es la cita canales : java.util.concurrente SynchronousQueue

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X