Considerazioni Java Thread.sleep ()

3

Ho fatto alcuni test in un'app con cui sono stato coinvolto per un po 'di tempo, e sembra che parte del codice che abbiamo scritto stia causando una race condition.

Quello che sta succedendo è qualcosa di simile a questo:

//We make this call which resolves a task in a BPM service
//causing a process instance to flow to the next person/task
ServiceRemoteAPI.completeTask(taskId);

//We then make this call which depends on the complete resolution of the 
//original call.
Tasks userTasks = ServiceRemoteAPI.tasksUserHasAvailable(nextUser);

//And we use those tasks to send an e-mail
for(Task task : userTasks){
    if(task == rightTask){
       sendEmail();
    }
}

Il problema è che in alcuni casi la chiamata API remota originale non si sta risolvendo completamente prima di eseguire la seconda, e ciò sta causando un comportamento irregolare. Quindi stavo pensando di fare qualcosa del genere:

ServiceRemoteAPI.completeTask(taskId);

**Thread.sleep(5000);**

Tasks userTasks = ServiceRemoteAPI.tasksUserHasAvailable(nextUser);

for(Task task : userTasks){
    if(task == rightTask){
       sendEmail();
    }
}

La domanda è, però, che non ho fatto molte discussioni prima, e sulla base delle mie ricerche questo sembra essere l'uso appropriato di Thread.sleep (), ma mi chiedo se ci sia qualcosa che mi manca, o se c'è un modo più robusto per realizzare ciò che mi piacerebbe ottenere qui.

    
posta Canadian Coder 16.12.2015 - 21:28
fonte

2 risposte

6

Mai sospendi un thread per X volta a dai all'API il tempo di elaborare qualcosa . Potrebbe sembrare che questo problema risolva il problema, ma non impedisce le condizioni di gara , anche se in tutti i tuoi test non vedi più la condizione della gara. È solo non garantito .

Nella mia esperienza, Thread.sleep() è una funzione terribilmente inutile.

Quello che dovresti fare è mettere in pausa il thread principale (o qualunque thread stia effettuando la seconda chiamata) fino a quando non ottieni la risposta dal primo thread (la tua prima chiamata API ).

Google semaforo e leggi un po '. Fondamentalmente non si autorizza l' altro thread a funzionare finché non viene eseguito quello corrente che fa parte della sezione critica (qualsiasi elaborazione che necessiti di si verificano). Puoi pensare a corrente qui per indicare la tua prima richiesta all'API e altro come thread che avvia / aspetta la seconda chiamata API.

    
risposta data 16.12.2015 - 23:29
fonte
1

In alternativa al bel suggerimento di @Chris: Accoda le richieste email . In questo modo escono sempre in ordine. Ad esempio, invii un "incontriamoci alle 12:30" seguito da "oops - la riunione è arrivata in ritardo, ci vediamo alle 1:00".

Se l'ordine è conservato, il destinatario dovrebbe capire. Se l'ordine è indeterminato, ci sono ottime possibilità che si presentino nel momento sbagliato.

Questo è un esempio banale, ma, seriamente, avevamo un'applicazione multi-thread multi-thread molto complessa, e la maggior parte dei problemi di race condition o out-of-order potevano essere risolti aggiungendo un'altra coda.

    
risposta data 17.12.2015 - 03:48
fonte

Leggi altre domande sui tag