"Ciao, Amigo! Devi ammettere che l'idea dell'annullamento di Ellie è stata geniale."

"Sì."

"In realtà, qualcosa di simile esiste nella classe Thread . Solo che la variabile non si chiama isCancel . Si chiama isInterrupt . E il metodo usato per fermare il thread non è cancel() . È interrupt() ."

"Veramente?"

"Sì. Dai un'occhiata:"

Codice Descrizione 
class Clock implements Runnable
{
public void run()
{
Thread current = Thread.currentThread();

while (!current.isInterrupted())
{
Thread.sleep(1000);
System.out.println("Tick");
}
}
}
 Poiché diversi thread possono chiamare il metodo run sullo stesso oggetto Clock, otteniamo l'oggetto Thread per il thread corrente .

La classe Clock scrive la parola "Tick" nella console una volta al secondo fintanto che la variabile isInterrupt del thread corrente è false.

Quando isInterrupt diventa true , il metodo run  termina.

 
public static void main(String[] args)
{
Clock clock = new Clock();
Thread clockThread = new Thread(clock);
clockThread.start();

Thread.sleep(10000);
clockThread.interrupt();
}
 Il thread principale avvia un thread figlio (orologio) che dovrebbe essere eseguito per sempre.

Attendere 10 secondi e  annullare l'attività chiamando il metodo di interruzione .

Il thread principale completa il suo lavoro.

Il filo dell'orologio termina il suo lavoro.
Java university

Inoltre, il metodo sleep , che le persone amano così tanto usare in cicli infiniti nel metodo run , controlla automaticamente la variabile isInterrupt . Se un thread chiama il metodo sleep , il metodo controlla innanzitutto se isInterrupt è vero per quel thread. Se è vero, il metodo non dormirà. Al contrario, genera un'eccezione InterruptedException .

"Perché lanciare un'eccezione? Non sarebbe meglio mettere semplicemente isInterrupted() invece di isCancel() in un ciclo?"

" In primo luogo , il metodo run non ha sempre un ciclo. Il metodo potrebbe consistere semplicemente in poche dozzine di chiamate ad altri metodi. Quindi dovresti aggiungere un controllo isInterrupted prima di ogni chiamata al metodo."

" In secondo luogo , alcuni metodi che comportano molte azioni diverse potrebbero richiedere molto tempo per essere eseguiti."

" In terzo luogo , il lancio di un'eccezione non sostituisce il controllo isInterrupted. È solo un'aggiunta utile. L'eccezione generata consente di srotolare rapidamente lo stack di chiamate al metodo run stesso."

" In quarto luogo , il metodo sleep è molto utilizzato. A quanto pare, questo metodo utile è migliorato da un controllo implicito che non è meno utile. È come se nessuno avesse aggiunto specificamente il controllo, ma è così. Questo è estremamente prezioso quando stai usando il codice di qualcun altro e non puoi aggiungere tu stesso il controllo."

" Quinto , il controllo aggiuntivo non degrada le prestazioni. Chiamare il metodo sleep significa che il thread non dovrebbe fare nulla (tranne dormire), quindi il lavoro extra non infastidisce nessuno."

"Questi sono argomenti seri."

"E, infine , c'è questo: il tuo metodo run può chiamare il codice di qualcun altro, codice a cui non hai accesso (codice sorgente e/o diritti per modificare il codice). Potrebbe non avere controlli isInterrupted e potrebbe usare " try ... catch (Exception e) " per catturare tutte le eccezioni."

Nessuno può garantire che un thread verrà interrotto. Solo un filo può arrestarsi.