che differenza tra tasso fisso e ritardo fisso in primavera programma?
Sto implementando le attività pianificate usando spring e vedo che il tempo di configurazione di tipo 2 funziona di nuovo dall'ultimo. Che differenza tra 2 digitare questa configurazione.
@Scheduled(fixedDelay = 5000)
public void doJobDelay() {
// do anything
}
@Scheduled(fixedRate = 5000)
public void doJobRate() {
// do anything
}
5 answers
- fixedRate: fa in modo che Spring esegua l'attività su intervalli periodici anche se l'ultima invocazione potrebbe essere ancora in esecuzione.
- fixedDelay: controlla specificamente il tempo di esecuzione successivo quando il l'ultima esecuzione finisce.
Nel codice:
@Scheduled(fixedDelay=5000)
public void updateEmployeeInventory(){
System.out.println("employee inventory will be updated once only the last updated finished ");
/**
* add your scheduled job logic here
*/
}
@Scheduled(fixedRate=5000)
public void updateEmployeeInventory(){
System.out.println("employee inventory will be updated every 5 seconds from prior updated has stared, regardless it is finished or not");
/**
* add your scheduled job logic here
*/
}
FixedRate: Viene utilizzato per eseguire il metodo job in ogni n millisecondi. Non è importante se il lavoro ha già terminato il suo compito precedente.
FixedDelay: Viene utilizzato per eseguire il metodo job in sequenza con il tempo di attesa n millisecondi specificato tra le attività.
Quando usare "fixedRate": fixedRate è appropriato se non si prevede che superi la dimensione della memoria e del pool di thread. Se le attività in arrivo non terminano veloce, potrebbe finire con "Eccezione di memoria esaurita"
Quando usare "fixedDelay": Se ogni attività in esecuzione è rilevante l'una per l'altra e devono attendere prima che finisca quella precedente, fixedRate è adatto. Se fixedDelay time è impostato con attenzione, lascerà anche ai thread in esecuzione abbastanza tempo per terminare i loro lavori prima che inizi la nuova attività
"fixedRate" : attende X millis dall'inizio dell'esecuzione precedente prima di iniziare l'esecuzione successiva. Se l'esecuzione corrente supera l'intervallo 'fixedRate', l'esecuzione successiva viene messa in coda, ma solo quella successiva. Non creerà serie di esecuzioni accodate
private static int i = 0;
@Scheduled(initialDelay=1000, fixedRate=1000)
public void testScheduling() throws InterruptedException {
System.out.println("Started : "+ ++i);
Thread.sleep(4000);
System.out.println("Finished : "+ i);
}
Uscita:
Iniziato: 1
Finito: 1 / / dopo 4 secondi
Avviato: 2 / / immediatamente senza attendere 1 sec come specificato in tasso fisso
Finito: 2 / / dopo 4 secondi
e così via
"fixedDelay" : attende X millis dalla fine dell'esecuzione precedente prima di iniziare l'esecuzione successiva. Non importa quanto tempo sta impiegando l'esecuzione corrente, l'esecuzione successiva viene avviata dopo aver aggiunto l'intervallo 'fixedDelay' all'ora di fine dell'esecuzione corrente. Non accoderà la prossima esecuzione.
private static int i = 0;
@Scheduled(initialDelay=1000, fixedDelay=1000)
public void testScheduling() throws InterruptedException {
System.out.println("Started : "+ ++i);
Thread.sleep(4000);
System.out.println("Finished : "+ i);
}
Uscita:
Iniziato: 1
Finito: 1 / / dopo 4 secondi iniziato : 2 / / attende 1 secondo come specificato in fixedDelay Finito: 2 / / dopo 4 secondi Iniziato: 3 / / dopo 1 secondo
e così via
Delay fisso: controlla specificamente l'ora di esecuzione successiva al termine dell'ultima esecuzione.
Tasso fisso : consente a Spring di eseguire l'attività a intervalli periodici anche se l'ultima chiamata potrebbe essere ancora in esecuzione.
Una cosa che dovrebbe essere chiarita è che fixedRate non significa che le esecuzioni inizieranno con un certo intervallo di tempo.
Se un'esecuzione costa troppo tempo (più del tasso fisso), l'esecuzione successiva inizierà solo DOPO la fine di della precedente, a meno che non vengano forniti @Async e @EnableAsync. I seguenti codici sorgente che fanno parte dell'implementazione ThreadPoolTaskScheduler di Spring spiegano perché:
@Override
public void run() {
Date actualExecutionTime = new Date();
super.run();
Date completionTime = new Date();
synchronized (this.triggerContextMonitor) {
this.triggerContext.update(this.scheduledExecutionTime, actualExecutionTime, completionTime);
if (!this.currentFuture.isCancelled()) {
schedule();
}
}
}
È possibile vedere che solo al termine dell'attività precedente (super.run()), il l'attività successiva è pianificata (schedule()). Con @Async e @EnableAsync, super.run() è una funzione asincrona che tornerà immediatamente, quindi l'attività successiva non deve attendere che quella precedente finisca effettivamente.