java - sirve - Por qué Thread.sleep es malo de usar

thread.sleep java

Question

Disculpas por esta pregunta repetida pero todavía no he encontrado ninguna respuesta satisfactoria. La mayor parte de la pregunta tenía su propio caso de uso específico:
Java - alternativa a thread.sleep
¿Hay alguna forma mejor o alternativa de omitir / evitar el uso de Thread.sleep (1000) en Java?

Mi pregunta es para el caso de uso muy genérico. Espere a que se complete una condición. Hacer alguna operacion Compruebe si hay una condición. Si la condición no es verdadera, espere un tiempo y vuelva a realizar la misma operación.

Por ejemplo, considere un método que crea una tabla de DynamoDB llamando a su tabla createAPI. La tabla DynamoDB tarda algún tiempo en activarse, por lo que el método llamaría a su API DescribeTable para sondear el estado a intervalos regulares hasta cierto tiempo (digamos 5 minutos; la desviación debida a la programación de subprocesos es aceptable). Devuelve verdadero si la tabla se activa en 5 minutos, de lo contrario, lanza una excepción.

Aquí está el pseudo código:

public void createDynamoDBTable(String name) {
  //call create table API to initiate table creation

  //wait for table to become active
  long endTime = System.currentTimeMillis() + MAX_WAIT_TIME_FOR_TABLE_CREATE;

  while(System.currentTimeMillis() < endTime) {
    boolean status =  //call DescribeTable API to get status;
    if(status) {
         //status is now true, return
         return
    } else {
        try {
            Thread.sleep(10*1000);
        } catch(InterruptedException e) {
        }
    }
  }

  throw new RuntimeException("Table still not created");
}

Entiendo que al usar Thread.sleep bloquea el subproceso actual, por lo que consume recursos. pero en una aplicación de tamaño bastante medio, ¿es un tema una gran preocupación?
Leí en alguna parte que use ScheduledThreadPoolExecutor y hago este sondeo de estado allí. Pero nuevamente, tendríamos que inicializar este grupo con al menos 1 hilo donde se ejecutaría el método ejecutable para hacer el sondeo.

Cualquier sugerencia sobre por qué usar Thread.sleep se dice que es una mala idea y cuáles son las opciones alternativas para lograr lo mismo que arriba.

http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx

Answer 1

Está bien usar Thread.sleep en esa situación. La razón por la que la gente desalienta a Thread.sleep es porque se usa con frecuencia en un mal intento de arreglar una condición de carrera, cuando la sincronización basada en notificaciones es una opción mucho mejor, etc.

En este caso, AFAIK no tiene una opción, pero la encuesta porque la API no le proporciona notificaciones. También puedo ver que es una operación poco frecuente porque, presumiblemente, no va a crear miles de tablas.

Por lo tanto, me parece bien usar Thread.sleep aquí. Como dijiste, generar un hilo separado cuando de todos modos vas a bloquear el hilo actual parece complicar las cosas sin mérito.

Answer 2

Sí, se debe intentar evitar el uso de Thread.sleep (x) pero no se debe olvidar por completo:

¿Por qué debería evitarse?

• No libera la cerradura.
• No se garantiza que la ejecución comience después de la hora de dormir (por lo que puede seguir esperando para siempre, obviamente es un caso raro )
• Si equivocadamente pusimos un subproceso de procesamiento de primer plano en suspensión, no podríamos cerrar esa aplicación hasta x milisegundos.
• Ahora estamos completamente cargados con un nuevo paquete de concurrencia para problemas específicos (como patrones de diseño (por supuesto, no exactamente ), por qué usar Thread.sleep (x) en ese momento.

Donde usar Thread.sleep (x):

• Para proporcionar retrasos en subprocesos en ejecución de fondo
• Y pocos más.