while - java switch sentence

Java: ¿Es malo el bucle `while(true){...}` en un hilo? ¿Cuál es la alternativa?

Question

¿Es malo while (true) { ... } hilo? ¿Cuál es la alternativa?

Actualizar; a lo que intento ...

Tengo ~ 10,000 hilos, cada uno consumiendo mensajes de sus colas privadas. Tengo un hilo que produce mensajes uno por uno y los coloca en la cola correcta del consumidor. Cada hilo de consumidor realiza un ciclo indefinidamente, verifica que aparezca un mensaje en su cola y lo procesa.

Dentro de Consumer.java:

@Override
public void run() {
while (true) {
Message msg = messageQueue.poll();
if (msg != null) {
... // do something with the message
}
}
}

El productor está poniendo mensajes dentro de las colas de mensajes del consumidor a un ritmo rápido (varios millones de mensajes por segundo). ¡Los consumidores deben procesar estos mensajes lo más rápido posible!

Nota: while (true) { ... } finaliza con un mensaje KILL enviado por el Productor como último mensaje. Sin embargo, mi pregunta es acerca de la forma correcta de hacer este mensaje de paso ...

Por favor vea la nueva pregunta , con respecto a este diseño.

Answer 1

Depende de la definición de "malo". Significa que la persona que intenta leer el código debe buscar en otra parte por el motivo de que el ciclo ha finalizado. Eso puede hacerlo menos legible.

Esta mentalidad llevada al extremo resulta en la palabra clave COMEFROM. http://en.wikipedia.org/wiki/COMEFROM

10 COMEFROM 40
20 INPUT "WHAT IS YOUR NAME? "; A$
30 PRINT "HELLO, "; A$
40 REM

Answer 2

En lugar de iterar por siempre y romper o regresar, puede optar por verificar el estado interrumpido.

while (!Thread.currentThread().isInterrupted()) {
try {
doWork();
wait(1000);
} catch (InterruptedException ex) {
Thread.currentThread().interrupt();
}
}

Si sus subprocesos son tareas administradas por un ExecutorService, puede hacer que todos finalicen de forma sencilla simplemente llamando a shutdownNow ().

Answer 3

Es mejor tener la condición de terminación en la línea while (...) , pero a veces la condición de terminación es algo que solo se puede probar en algún lugar en el interior del bucle. Entonces, para eso es la break (o excepciones). De hecho, tal vez su hilo debe ejecutarse para siempre hasta que su programa finalice (con System.exit ); entonces while (true) es definitivamente correcto.

Pero tal vez estás preguntando qué debería ir dentro del ciclo. Debes asegurarte de incluir alguna operación de bloqueo, es decir, alguna llamada a función donde tu hilo esperará a que otra persona (otro hilo, otro programa, el sistema operativo) haga algo. Esto suele ser Condition.wait si está programando con bloqueos, o leyendo desde una cola de mensajes, o leyendo desde un archivo o conector de red, o alguna otra operación de bloqueo de E / S.

Tenga en cuenta que sleep generalmente no es lo suficientemente bueno. No puede saber cuándo otros participantes van a hacer algo, por lo que no hay forma de evitar despertarse con demasiada frecuencia (lo que quema el tiempo de la CPU innecesariamente) o muy raramente (por lo tanto, no reacciona a los eventos de manera oportuna). Siempre diseñe su sistema para que cuando un hilo haya completado su trabajo, notifique a quien esté esperando en ese trabajo (a menudo con Condition.signal o uniéndose).

Answer 4

No inherentemente, no. Siempre puedes fianza usando break o return . Solo asegúrate de que realmente lo hagas (en algún momento)

El problema es qué sucede cuando tu hilo no tiene nada que hacer? Si solo das vueltas y vueltas para verificar una condición, tu hilo consumirá toda la CPU sin hacer nada. Así que asegúrese de usar wait para hacer que su thread se bloquee, o sleep si no tiene que wait .

Answer 5

Normalmente voy con un atributo de clase booleano llamado ''hecho'', luego los métodos de ejecución de los hilos se ven como

done = false;
while( !done ) {
// ... process stuff
}

Luego puede establecer done = true para matar el ciclo. Esto se puede hacer desde adentro del bucle, o puede tener otro método que lo configure, para que otros hilos puedan desconectarse.

Answer 6

Parece que estás ocupado esperando, asumiendo un BlockingQueue estándar. Usa take lugar de poll .

Aparte de eso, for (;;) es mejor que while (true) , IMO.

Answer 7

Por lo general, querrás wait un recurso de algún tipo para hacer el trabajo, que oculta los detalles reales de enhebrado. Parece que querías implementar tu propio spinlock .

Aquí hay un tutorial sobre el bloqueo que encontré en google.

Answer 8

Si fuera a hacer lo que estás tratando, intentaría esto:

private Object lock = new Object();
public void run(){
while(true){
synchronized(lock){
Message msg = messageQueue.poll();
if (msg != null) {
... // do something with the message
}else{
try{
lock.wait();
}catch(InterruptedException e){
e.printStackTrace();
continue;
}
}
}
}
}

Esto le permite asegurarse de que no obtiene ninguna exepción de modificación concurrente en su MessageQueue, así como tampoco cuando no hay mensaje de que no usará el tiempo de CPU en el ciclo while (verdadero). Ahora solo necesita asegurarse de que cuando agrega algo a su MessageQueue, puede llamar a lock.notifyAll() para que el hilo sepa que se debe volver a ejecutar.

Answer 9

while (true) no está mal si hay una manera de salir del loop, de lo contrario la llamada se ejecutará indefinidamente.

Para 10000 subprocesos hacer la llamada while(true) es una mala práctica ... ¿por qué no tienes un sleep() en el subproceso para permitir que se ejecuten otros subprocesos o una estrategia de salida si el subproceso finaliza la ejecución?

Answer 10

while (!stop_running) { ... }

...¿quizás? Una especie de indicador de salida se usa a menudo para controlar la ejecución de subprocesos.