sleepen - thread sleep 500 java

Thread.sleep() en un ciclo while

Question

Observé que NetBeans me advirtió sobre el uso de Thread.sleep () en un ciclo while en mi código Java, así que hice algunas investigaciones sobre el tema. Parece que el problema principal es el rendimiento, donde su condición de tiempo puede convertirse en realidad mientras el contador todavía está durmiendo, perdiendo el tiempo del reloj de pared mientras espera la próxima iteración. Todo esto tiene perfecto sentido.

Mi aplicación necesita contactarse con un sistema remoto y sondear periódicamente el estado de una operación, esperando hasta que la operación se complete antes de enviar la próxima solicitud. Por el momento, el código lógicamente hace esto:

String state = get state via RPC call
while (!state.equals("complete")) {
    Thread.sleep(10000); // Wait 10 seconds
    state = {update state via RPC call}
}

Dado que la circunstancia es la comprobación de una operación remota (que es un proceso un tanto costoso, ya que se ejecuta durante varios segundos), ¿se trata de un uso válido de Thread.sleep () en un ciclo while? ¿Hay una mejor manera de estructurar esta lógica? He visto algunos ejemplos en los que podría usar una clase Timer, pero no veo el beneficio, ya que todavía parece reducirse a la misma lógica directa anterior, pero con mucha más complejidad.

Tenga en cuenta que el sistema remoto en este caso no está bajo mi control directo, ni está escrito en Java, por lo que cambiar ese extremo para ser más "cooperativo" en este escenario no es una opción. Mi única opción para actualizar el valor de estado de mi aplicación es crear y enviar un mensaje XML, recibir una respuesta, analizarlo y luego extraer la información que necesito.

Cualquier sugerencia o comentario sería bienvenido.

Answer 1

A menos que su sistema remoto pueda emitir un evento o notificarlo de manera asincrónica, no creo que lo anterior sea del todo irracional. Necesita equilibrar el tiempo de sleep() frente al tiempo / carga que genera la llamada de RPC, pero creo que ese es el único problema y lo anterior no parece preocupar en absoluto.

Answer 2

Deberías (casi) nunca usar el sueño ya que es muy ineficiente y no es una buena práctica. Utilice siempre bloqueos y variables de condición donde los hilos se señalizan entre sí. Ver los estándares de codificación de Mike Dahlin para la programación con hilos

Una plantilla es:

public class Foo{
  private Lock lock;
  private Condition c1;
  private Condition c2;

  public Foo()
  {
    lock = new SimpleLock();
    c1 = lock.newCondition();
    c2 = lock.newCondition();
    ...
  }

  public void doIt()
  {
    try{
      lock.lock();
      ...
      while(...){
        c1.awaitUninterruptibly();
      }
      ...
      c2.signal();
    }
    finally{
      lock.unlock();
    }
  }
}

Answer 3

Sin poder cambiar el extremo remoto para proporcionar una notificación de "envío" que se realiza con su proceso de larga ejecución, es lo mejor que podrá hacer. Siempre que el tiempo de subproceso sea largo en comparación con el costo de la votación, debería estar bien.