Problema de rendimiento de Java con Thread.sleep()

Question

Inline Java IDE Sugerencia: "Invocar Thread.sleep in loop puede causar problemas de rendimiento". No puedo encontrar elucidación en ningún otro lugar de los documentos. esta declaración.

¿Por qué? ¿Cómo? ¿Qué otro método podría haber para retrasar la ejecución de un hilo?

Answer 1

Depende de si la espera depende de otro hilo que complete el trabajo, en cuyo caso debe usar , o high level concurrency classes introducido en Java 1.6. Recientemente tuve que arreglar un código CircularByteBuffer que utilizaba Thread sleeps en lugar de bloques protegidos. Con el método anterior, no había forma de garantizar una concurrencia adecuada. Si solo quieres que el subproceso duerma como lo haría un juego, en el bucle principal del juego para pausar la ejecución durante un cierto período de tiempo para que los subprocesos tengan un buen período de ejecución, Thread.sleep(..) está perfectamente bien.

Answer 2

No es que Thread.sleep en un bucle en sí es un problema de rendimiento, pero por lo general es una pista de que está haciendo algo mal.

while(! goodToGoOnNow()) { 
    Thread.sleep(1000); 
} 

Uso Thread.sleep sólo si desea suspender el hilo por una cierta cantidad de tiempo. No lo use si desea esperar una determinada condición.

Para esta situación, debe usar wait/notify en su lugar o algunas de las construcciones en los paquetes de simultaneidad.

El sondeo con Thread.sleep debe usarse solo cuando se esperan condiciones externas a la JVM actual (por ejemplo, esperar hasta que otro proceso haya escrito un archivo).

Answer 3

Depende de por qué lo está durmiendo y con qué frecuencia lo ejecuta.

puedo pensar en varias alternativas que se podrían aplicar en diferentes situaciones:

• dejar morir al hilo y comenzar uno nuevo más tarde (la creación de hilos puede ser demasiado caro)
• Uso Thread.join() esperar a que otro hilo de morir
• uso Thread.yield() para permitir que otro hilo para ejecutar
• deja pasar el hilo, pero lo puso a una prioridad más baja
• Use wait() and notify()

Answer 4

Sugiero buscar en la clase CountDownLatch. Hay bastantes ejemplos triviales en línea. Cuando recién comencé la programación multiproceso, eran solo el boleto para reemplazar un "ciclo while sleeping".

Answer 5

¿por qué? eso es debido a la conmutación de contexto (parte de la programación de la CPU del sistema operativo)

¿Cómo? llamar a Thread.sleep (t) hace que el hilo actual se mueva de la cola en ejecución a la cola de espera. Después de que el tiempo 't' alcanza el hilo actual se mueve de la cola de espera a la lista de espera y luego toma un tiempo para ser recogido por la CPU y en ejecución.

Solución: llame a Thread.sleep (t * 10); en lugar de llamar a Thread.Sleep (t) dentro del ciclo de 10 iteraciones ...

Answer 6

Me he enfrentado a este problema antes cuando esperaba que el proceso asincrónico devolviera un resultado.

Thread.sleep es un problema en el escenario de subprocesos múltiples. Tiende a quedarse dormido. Esto se debe a que internamente reorganiza su prioridad y cede a otros procesos de larga ejecución (subprocesos).

Un nuevo enfoque está utilizando la interfaz ScheduledExecutorService o la ScheduledThreadPoolExecutor introducen en java 5.

Referencia: http://download.oracle.com/javase/1,5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html

Answer 7

http://www.jsresources.org/faq_performance.html

1,6. ¿Qué precisión puedo esperar de Thread.sleep()?

El problema fundamental con las estancias cortas es que una llamada al modo de suspensión finaliza el segmento de tiempo de programación actual. Solo después de que todos los demás hilos/proceso hayan terminado, la llamada puede regresar.

Para Sun JDK, se dice que Thread.sleep (1) es bastante preciso en Windows. Para Linux, depende de la interrupción del temporizador del kernel. Si el kernel se compila con HZ = 1000 (el valor predeterminado es alfa), se informa que la precisión es buena. Para HZ = 100 (el valor predeterminado en x86), normalmente duerme durante 20 ms.

El uso de Thread.sleep (millis, nanos) no mejora los resultados. En Sun JDK, el valor de nanosegundos se redondea al milisegundo más cercano. (Matthias)

Answer 8

Puede que NO sea un problema, depende.

En mi caso, uso Thread.sleep() para esperar unos segundos antes de otro intento de reconexión a un proceso externo. Tengo un ciclo while para esta lógica de reconexión hasta que alcanza el máximo de # intentos. Entonces en mi caso, Thread.sleep() es puramente para el propósito del tiempo y no se coordina entre los hilos múltiples, está perfectamente bien.

Puede configurar su IDE en cómo se debe manejar esta advertencia.