2010-03-09 12 views
6

Tengo varios hilos cada uno con su propia cola concurrente privada y todo lo que hacen es ejecutar un bucle infinito recuperando mensajes de él. Podría suceder que una de las colas no reciba mensajes durante un período de tiempo (tal vez un par de segundos), y también podrían venir en grandes ráfagas y es necesario un procesamiento rápido.concurrencia de Java: ¿debería bloquearse o ceder?

Me gustaría saber cuál sería el más apropiado para hacer en el primer caso: usar una cola de bloqueo y bloquear el hilo hasta que tenga más información o haga un Thread.yield()?

Quiero tener todos los recursos de CPU disponibles en un momento dado, ya que el número de subprocesos simultáneos puede aumentar con el tiempo, pero también no quiero que el proceso de mensajes se quede atrás, ya que no hay garantía de cuándo se volverá a programar el hilo para su ejecución cuando se realiza un rendimiento(). Sé que el hardware, el sistema operativo y otros factores juegan un papel importante aquí, pero dejando eso de lado y mirándolo desde un punto de vista Java (JVM?), ¿Cuál sería el más óptimo?

Respuesta

9

Siempre bloquee las colas. Java cede internamente en las colas.

En otras palabras: no puede obtener ningún beneficio de rendimiento en los otros hilos si cede en uno de ellos en lugar de simplemente bloquear.

+0

NO, solo intente la biblioteca [disruptor] (https://github.com/LMAX-Exchange/disruptor). ¡Parece el mejor rendimiento conseguido solo por el rendimiento! – qinxian

7

Ciertamente desea utilizar una cola de bloqueo: están diseñadas exactamente para este propósito (desea que sus hilos no usen el tiempo de CPU cuando no hay trabajo que hacer).

Thread.yield() es una bestia extremadamente temperamental: el programador juega un papel importante en lo que hace; y una implementación simple pero válida es simplemente no hacer nada.

0

Alternativamente, considere convertir su implementación para usar una de las implementaciones ExecutorService administradas - probablemente ThreadPoolExecutor.

Esto puede no ser apropiado para su caso de uso, pero si lo es, elimina toda la carga de preocuparse por la administración de subprocesos de su propio código, y estas preguntas sobre ceder o no simplemente desaparecen.

Además, si surgen mejores algoritmos de administración de subprocesos en el futuro, por ejemplo, algo parecido al Grand Central Dispatch de Apple, es posible que pueda convertir su aplicación para usarla sin apenas esfuerzo.

0

Otra cosa que podría hacer es usar el mapa hash concurrente para su cola. Cuando haces una lectura, te da una referencia del objeto que estabas buscando, por lo que es posible que pierda un mensaje que acaba de poner en la cola. Pero si todo esto es escuchar un mensaje, lo verás la próxima iteración. Sería diferente si los mensajes pudieran ser actualizados por otros hilos. Pero realmente no parece haber una razón para bloquear lo que puedo ver.

Cuestiones relacionadas