Domanda

Ho trovato simili domande poste qui, ma non c'erano risposte per la mia soddisfazione. Così riformulare la questione ancora una volta -

Ho un compito che deve essere fatto su base periodica (diciamo intervalli di 1 minuto). Qual è il vantaggio di utilizzare TimerTask & Timer per fare questo invece di creare un nuovo thread che ha un ciclo infinito con il sonno?

Snippet di codice utilizzando TimerTask -

TimerTask uploadCheckerTimerTask = new TimerTask(){

 public void run() {
  NewUploadServer.getInstance().checkAndUploadFiles();
 }
};

Timer uploadCheckerTimer = new Timer(true);
uploadCheckerTimer.scheduleAtFixedRate(uploadCheckerTimerTask, 0, 60 * 1000);

frammento di codice con filo e dormire -

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

io davvero non si deve preoccupare se manco certi cicli se l'esecuzione della logica richiede più l'intervallo di tempo.

Si prega di commentare questo ..

Aggiornamento:
Recentemente ho trovato un'altra differenza tra l'utilizzo di Timer contro Thread.sleep (). Supponiamo che il tempo di sistema attuale è 11:00. Se ROLLBACK il tempo di sistema 10:00 am per qualche ragione, il timer di STOP esecuzione del compito fino al raggiungimento 11:00, metodo che Thread.sleep () continuerà l'esecuzione del compito senza ostacoli. Questo può essere un importante decisore a decidere cosa usare tra questi due.

È stato utile?

Soluzione

Il vantaggio di TimerTask è che esso esprime l'intenzione molto meglio (vale a dire la leggibilità del codice), e ha già la funzione di cancellazione () implementato.

Si noti che può essere scritto in una forma più breve così come il vostro esempio:

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

Altri suggerimenti

Timer / TimerTask prende in considerazione anche il tempo di esecuzione del vostro compito, quindi sarà un po 'più preciso. E si tratta meglio con problemi di multithreading (come ad esempio evitare situazioni di stallo, ecc). E, naturalmente, di solito è meglio usare codice standard collaudato al posto di qualche soluzione fatta in casa.

Non so perché, ma un programma che stavo scrivendo stavo usando temporizzatori ed è dimensione heap è stato in costante aumento, una volta che l'ho cambiato a questo argomento / problema di sonno risolto.

Se si ottiene infilare eccezione e viene ucciso, questo è un problema. Ma TimerTask si prenderà cura di esso. Verrà eseguito a prescindere dal fallimento nella precedente esecuzione.

C'è un argomento cruciale contro la gestione di questa operazione utilizzando i thread Java e il metodo sleep. Si utilizza while(true) di rimanere a tempo indeterminato nel ciclo e ibernare il filo mettendo a dormire. Che cosa succede se NewUploadServer.getInstance().checkAndUploadFiles(); riprende alcune risorse sincronizzate. Altre discussioni saranno in grado di accedere a queste risorse, la fame può accadere che può rallentare l'intera applicazione. Questi tipi di errori sono difficili da diagnosticare ed è una buona idea per impedire la loro esistenza.

L'altra aproach attiva l'esecuzione del codice che conta per voi, vale a dire NewUploadServer.getInstance().checkAndUploadFiles(); chiamando il metodo run() del vostro TimerTask mentre lasciando altri thread che utilizzano le risorse nel frattempo.

Dal Timer documentazione :

  

Java 5.0 ha introdotto il pacchetto java.util.concurrent e uno dei   utilità concorrenza detta disposizione è la ScheduledThreadPoolExecutor che   è un pool di thread per le attività volte esecuzione ad un determinato tasso o   ritardo. È effettivamente una sostituzione più versatile per la   Temporizzatore / combinazione TimerTask, in quanto consente a più thread di servizio,   accetta varie unità di tempo, e non richiede la creazione di sottoclassi TimerTask   (Basta implementare Runnable). Configurazione ScheduledThreadPoolExecutor   con un filo rende equivalente a Timer.

Così Preferisco ScheduledThreadExecutor invece di Timer:

  • Timer utilizza thread in background singolo che viene utilizzato per eseguire tutti i compiti del timer, in modo sequenziale. Quindi compiti dovrebbero completare rapidamente il resto sarà ritardare l'esecuzione di attività successive. Ma in caso di ScheduledThreadPoolExecutor siamo in grado di configurare qualsiasi numero di thread e può anche avere il pieno controllo, fornendo ThreadFactory.
  • Timer può essere sensibile al clock di sistema in quanto fa uso di metodo Object.wait(long). Ma non è ScheduledThreadPoolExecutor.
  • eccezioni runtime gettato in TimerTask uccideranno quel filo particolare, rendendo così Timer morti dove, come possiamo gestire che in ScheduledThreadPoolExecutor in modo che gli altri compiti non sono interessati.
  • Timer fornisce metodo cancel per terminare il timer e scartare eventuali operazioni programmate, tuttavia non interferisce con l'attività in corso di esecuzione e lasciarlo finire. Ma se il timer viene eseguito come thread demone allora se si cancella o no, terminerà quando tutti i thread utente sono finiti esecuzione.

Timer vs Thread.sleep

Timer si avvale di Object.wait ed è diverso da Thread.sleep

  1. A attesa (wait) filo può essere notificato (utilizzando notify) da un altro thread ma un sonno non si può essere, può essere interrotta solo.
  2. A wait (e comunicare) devono avvenire in un blocco sincronizzato sul monitor oggetto, mentre il sonno non è così.
  3. durante il sonno non rilascia il blocco, in attesa rilascerà il blocco per l'oggetto di attesa è chiamato.

Credo di capire il problema, sto vedendo qualcosa di molto simile. Ho timer che sono ricorrenti, circa ogni 30 minuti e un po 'di ogni paio di giorni. Da quello che ho letto e le osservazioni che vedo, sembra che la raccolta dei rifiuti non verrà mai eseguito perché tutto il compito non sono mai completa. Vorrei pensare che la raccolta dei rifiuti avrebbe eseguito quando il timer è in stop, ma io non sto vedendo e secondo la documentazione non è così.

Credo che la deposizione delle uova nuove discussioni completa e consentire la raccolta dei rifiuti.

Qualcuno si prega di dimostrare il torto, riscrivendo ciò che ho ereditato sta per essere un dolore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top