Thread.Sleep alternativa en Java

Question

Me han dicho que utilizar Thread.Sleep() es una mala solución a veces que uno quisiera hacer un intervalo de tiempo dentro de un bucle de acciones en un método sincronizado.

Por otro lado, tengo dos subprocesos diferentes que están activos durante el tiempo de ejecución de mi programa y también un objeto compartido y cuando uso Object.wait (long) en ese objeto compartido, causa que mi GUI se congele durante algún tiempo.

¿cuál sería una mejor solución para este problema?

---

actualización Esta parte del código está incluyendo uno de los hilos que está comenzando en GUI:

class temperatureUp extends Thread { @Override public void run() { while(true) { try { GBC.increaseTemp(); updateSystemStatus(); } catch(Exception ex) { StringWriter w = new StringWriter(); ex.printStackTrace(new PrintWriter(w)); txtLog.setText(w + "\n" + txtLog.getText()); } } } };

y este es el método sincronizado en objeto compartido, GBC:

public synchronized void increaseTemp() throws InterruptedException{ 
    // don't increase the temperature if the boiler 
    // is not turned on... 
    while (!isBoilerOn) 
     wait(); 

    // increase the current temperature 
    if ((currentTemp + 1) < MAX_TEMP && currentTemp < desiredTemp) { 
     Thread.sleep(2000); ///what should put here if not thread sleep? 
     currentTemp ++;  
     updateGasBoilerStatus(); 
    } 
} 

Answer 1

Puede reducir el alcance de la declaración synchronize. Por ejemplo, si está realizando la sincronización de todo el método

public synchronized void foo() 

Podría quitar el modificador y el uso de un bloque sincronizado lugar

synchronized (this) { 
    // ... 
} 

y mover el Thread.sleep() fuera de este bloque si es posible. Solo sincronice en aquellas declaraciones que modifiquen estados de datos compartidos.

Muchos de los problemas de subprocesos relacionados con Swing están relacionados con el Event Dispatcher Thread y se pueden resolver fácilmente con él. Te recomiendo que leas.

Un poco de historia poco, ¿por qué no debería llamar Thread.sleep() dentro de un bloque de sincronización:

de albergue o en espera mientras se mantiene un bloqueo. Llamar a Thread.sleep con un bloqueo puede evitar que otros hilos progresen durante un tiempo largo de y, por lo tanto, es un riesgo de vitalidad potencialmente grave. Llamar a Object.wait o Condition.await con dos bloqueos retenidos plantea un peligro similar . [JCIP]

Answer 2

No dormir dentro del método sincronizado! ¡No espere en los manejadores de eventos GUI/métodos!

Divida las acciones sincronizadas para que la llamada Sleep() no se invoque en el contexto de la secuencia de comandos de la GUI.

Quizás use InvokeLater() para el segundo bit.

Answer 3

Me gustaría hacer uso de monitores: http://www.artima.com/insidejvm/ed2/threadsynch4.html Tal vez con notificar o notificar Todo lo que pueda resolverlo. ¡Buena suerte!

Answer 4

Mantenga siempre su subproceso Event Dispatcher Thread (EDT) que es responsable de manejar su GUI, lejos de cualquier trabajo que no sea de UI.Además, no sincronizar el método completo, pero sincronizar los enunciados atómicos

synchronized(this){ 
    //... 
} 

Answer 5

Puede probar este siguiente código:

public static void delay(int waitTime) { 
     long endTime = System.currentTimeMillis() + (waitTime * 1000); 
     while (System.currentTimeMillis() < endTime) {} 
    } 

llamada como retardo (5). Y el control esperará por 5 segundos.