loop - Timer & TimerTask versus Thread+sleep en Java

thread sleep 500 java

Question

Encontré preguntas similares aquí pero no hubo respuestas para mi satisfacción. Así que volviendo a formular la pregunta de nuevo-

Tengo una tarea que debe hacerse periódicamente (por ejemplo, intervalos de 1 minuto). ¿Cuál es la ventaja de utilizar Timertask & Timer para hacer esto en lugar de crear un nuevo hilo que tenga un ciclo infinito con sleep?

Fragmento de código con timertask-

TimerTask uploadCheckerTimerTask = new TimerTask(){
public void run() {
NewUploadServer.getInstance().checkAndUploadFiles();
}
};
Timer uploadCheckerTimer = new Timer(true);
uploadCheckerTimer.scheduleAtFixedRate(uploadCheckerTimerTask, 0, 60 * 1000);

Fragmento de código usando Subproceso y sleep-

Thread t = new Thread(){
public void run() {
while(true) {
NewUploadServer.getInstance().checkAndUploadFiles();
Thread.sleep(60 * 1000);
}
}
};
t.start();

Realmente no tengo que preocuparme si pierdo ciertos ciclos si la ejecución de la lógica requiere más tiempo que el intervalo.

Por favor comenta sobre esto ..

Gracias,
-Keshav

Actualizar:
Recientemente encontré otra diferencia entre usar Timer versus Thread.sleep (). Supongamos que la hora actual del sistema es 11:00 a.m. Si restituimos la hora del sistema a 10:00 a.m. por algún motivo, The Timer DEJARÁ de ejecutar la tarea hasta que haya llegado a las 11:00 AM, mientras que el método Thread.sleep () continuará ejecutando la tarea sin obstáculos. Este puede ser un importante tomador de decisiones al decidir qué usar entre estos dos.

Answer 1

Creo que entiendo tu problema, estoy viendo algo muy similar. Tengo temporizadores recurrentes, algunos cada 30 minutos y otros cada dos días. Por lo que leí y los comentarios que veo, parece que la recolección de basura nunca se ejecutará porque todas las tareas nunca se completan. Pensaría que la recolección de basura se ejecutaría cuando un temporizador está en reposo, pero no lo veo y, según la documentación, no.

Creo que el engendrar nuevos hilos completa y permite la recolección de basura.

Alguien por favor, demuéstrame que estoy equivocado, volver a escribir lo que heredé va a ser un dolor.

Answer 2

Hay un argumento crucial en contra de la administración de esta tarea usando los subprocesos de Java y sleep método de sleep . Está utilizando while(true) para permanecer indefinidamente en el ciclo e hibernar el hilo poniéndolo a dormir. ¿Qué NewUploadServer.getInstance().checkAndUploadFiles(); si NewUploadServer.getInstance().checkAndUploadFiles(); toma algunos recursos sincronizados. Otros hilos no podrán acceder a estos recursos, puede pasar hambre, lo que puede ralentizar toda su aplicación. Este tipo de errores son difíciles de diagnosticar y es una buena idea evitar su existencia.

El otro enfoque desencadena la ejecución del código que le interesa, es decir, NewUploadServer.getInstance().checkAndUploadFiles(); llamando al método run() de su TimerTask mientras permite que otros hilos usen los recursos mientras tanto.

Answer 3

La ventaja de TimerTask es que expresa su intención mucho mejor (es decir, la legibilidad del código) y ya tiene implementada la característica cancelar ().

Tenga en cuenta que se puede escribir en una forma más corta, así como su propio ejemplo:

Timer uploadCheckerTimer = new Timer(true);
uploadCheckerTimer.scheduleAtFixedRate(
new TimerTask() {
public void run() { NewUploadServer.getInstance().checkAndUploadFiles(); }
}, 0, 60 * 1000);

Answer 4

No sé por qué, pero un programa que estaba escribiendo usaba Timers y su tamaño de pila aumentaba constantemente, una vez que lo cambiaba a un problema de Thread / sleep resuelto.

Answer 5

Si recibes una excepción y te matan, es un problema. Pero TimerTask se encargará de eso. Se ejecutará independientemente de la falla en la ejecución anterior.

Answer 6

Timer / TimerTask también tiene en cuenta el tiempo de ejecución de su tarea, por lo que será un poco más preciso. Y funciona mejor con problemas de subprocesamiento múltiple (como evitar interbloqueos, etc.). Y, por supuesto, generalmente es mejor usar un código estándar bien probado en lugar de una solución casera.