Aquí podría ser tu PUBLICIDAD


¿Hay algo peligroso sobre usar Thread.currentThread.sleep () en mi código principal?

votos
3

en mi código que estoy usando

Thread.currentThread().sleep(sleepTime);

en la parte principal (no hilo) del código.

Parece que funciona bien, pero me preocupa que pueda haber alguna trampa oculta que me muerda el trasero más tarde.

¿Hay una mejor manera de hacer que su proceso principal permanezca por un tiempo? o es esta la metodología prescrita?

EDITAR:

En respuesta a por qué lo estoy haciendo de esta manera ...

Tengo un proceso que se conecta a través de HTTP o FTP a hosts remotos y hace cosas.

En otras palabras...

cosas...

conectarse a control remoto ...

hacer cosas con conexión remota ...

conexión cercana...

mas cosas...

repita según sea necesario.

Descubrí que, en casos muy raros, la conexión simplemente se va a la tierra. No falla, no arroja ninguna excepción, simplemente desaparece. Y está bloqueando, por lo que no hay una forma en línea de configurar un temporizador.

Entonces, mi solución es hacer esto ...

cosas...

iniciar nuevo hilo con conexión en él ...

entrar en un ciclo infinito con un temporizador en el proceso PRINCIPAL (no en el hilo generado) y esperar a que

a) el hilo de conexión para completar su tarea y establecer alguna bandera como hecho

o

b) espere un tiempo preestablecido y si el hilo de conexión no ha informado que ha finalizado, mátalo y continúe.

Es en el proceso principal donde tengo la intención de dormir durante un tiempo, me despierto y veo si el MAX_WAIT_TIME ha expirado. Si no, vuelve a dormir y espera un poco más.

Parece mucho más eficiente (en el procesador) que sentarse en un ciclo while estándar, ya que eso realmente interferiría con el negocio del hilo de conexión de hacer lo que tiene que hacer.

Creo que mi pregunta realmente es ... ¿hay algo inseguro en este enfoque? Veo por las respuestas que, dado lo que estoy haciendo, parece que no hay. Tal vez debería haber preguntado si hay un enfoque más estandarizado.

Publicado el 12/03/2009 a las 22:01
fuente por usuario Genia S.
En otros idiomas...        العربية       

8 respuestas

votos
13

¿Qué tipo de aplicación estás escribiendo? Rara vez es una buena idea, y es una idea particularmente mala si está escribiendo una GUI de cliente: mientras el hilo está durmiendo, no responderá.

Si pudiera dar más de una indicación de por qué necesita pausar y el tipo de aplicación que está escribiendo, eso sería útil.

Otra cosa: tu llamada debería ser:

Thread.sleep(sleepTime);

Llamarlo currentThread()hace que parezca un método de instancia, pero no lo es, es solo un método estático normal. No puedes hacer que ningún otro hilo duerma.

Debería ver si su IDE tiene una opción para hacer que llamar a los métodos estáticos a través de una referencia sea una advertencia o error; esto lleva a un código engañoso (como este).

Respondida el 12/03/2009 a las 10:05
fuente por usuario Jon Skeet


Aquí podría ser tu PUBLICIDAD


votos
4

No hay trampa. Dormirá todo el tiempo que diga.

Puede haber o no una trampa en la idea de que su aplicación se quede dormida durante un período prolongado de tiempo.

Respondida el 12/03/2009 a las 10:05
fuente por usuario mquander

votos
3

Bueno, Thread.sleep es un método estático por lo que es muy engañoso. Además, no se puede despertar limpiamente (puede interrumpir, pero disputaría que eso está limpio) en caso de que necesite que se cierre la acción.

Respondida el 12/03/2009 a las 10:05
fuente por usuario Tom Hawtin - tackline

votos
3

No es peligroso, pero en el 99 +% de los casos cuando crees que lo necesitas, realmente no. ¿Que estás tratando de hacer?

Respondida el 12/03/2009 a las 10:03
fuente por usuario erikkallen

votos
2

Si decide usar Thread.sleep , asegúrese de manejar la InterruptedException de manera adecuada .

Respondida el 12/03/2009 a las 10:34
fuente por usuario McDowell

votos
0

La gente a menudo usa el temporizador para realizar eventos diferidos, pero yo prefiero el ScheduleExecutorService. Puede usar el mismo grupo de subprocesos para todas sus acciones de tiempo de espera. (Puede tener un grupo de subprocesos de tamaño 1)

Respondida el 14/03/2009 a las 02:47
fuente por usuario Peter Lawrey

votos
0

AFAIR Thread.sleep()desperdicia tiempo de CPU mientras Object.wait(long timeout)que no. Por lo tanto, siempre debe usar Object.wait(long timeout)en su lugar. Aunque no puedo encontrar ningún metraje que respalde mi tesis, creo que al cambiar a Object.wait(long timeout)llamadas recibimos una gran ganancia de rendimiento.

Respondida el 14/03/2009 a las 01:46
fuente por usuario Daniel Hiller

votos
0

¿Qué quieres decir con que la conexión simplemente "se va"? Claro que no hay una forma en línea para configurar un temporizador, pero puede establecer un tiempo de espera de conexión Y tiempos de espera de lectura si lo desea.

Cree el socket con el constructor no-args, la llamada connect (SocketAddress, int) para que pueda establecer un tiempo de espera (en milisegundos). Si no se puede establecer la conexión en ese momento, se lanza una excepción.

Y puede llamar a setSoTimeout () antes de conectarse para que cualquier llamada a read () solo se bloquee durante el tiempo que especifique, en lugar de para siempre. Si no se pueden leer los datos en el tiempo especificado, se lanza una excepción.

Respondida el 12/03/2009 a las 11:01
fuente por usuario Chochos