"Hallo, Amigo! Je moet toegeven dat Ellie's Cancel-idee briljant was."

"Ja."

"Eigenlijk bestaat er iets soortgelijks in de klasse Thread . Alleen heet de variabele niet isCancel . Het heet isInterrupt . En de methode die wordt gebruikt om de thread te stoppen is niet cancel() . Het is interrupt() ."

"Echt?"

"Ja. Kijk eens:"

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

while (!current.isInterrupted())
{
Thread.sleep(1000);
System.out.println("Tick");
}
}
}
 Omdat verschillende threads de run-methode op hetzelfde Clock-object kunnen aanroepen, krijgen we het Thread-object voor de huidige thread .

De klasse Clock schrijft eenmaal per seconde het woord "Tick" naar de console zolang de variabele isInterrupt van de huidige thread onwaar is.

Wanneer isInterrupt true wordt , wordt de methode run  beëindigd.

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

Thread.sleep(10000);
clockThread.interrupt();
}
 De hoofdthread start een kinderthread (klok) die voor altijd zou moeten lopen.

Wacht 10 seconden en  annuleer de taak door de interruptmethode aan te roepen .

De rode draad voltooit zijn werk.

De klokdraad beëindigt zijn werk.
Java webinar

Bovendien controleert de sleep- methode, die mensen zo graag gebruiken in eindeloze lussen in de run- methode, automatisch de isInterrupt -variabele. Als een thread de slaapmethode aanroept , controleert de methode eerst of isInterrupt waar is voor die thread. Als het waar is, zal de methode niet slapen. In plaats daarvan wordt een InterruptedException- uitzondering gegenereerd .

"Waarom een ​​uitzondering maken? Zou het niet beter zijn om gewoon isInterrupted() in plaats van isCancel() in een lus te zetten?"

" Ten eerste heeft de methode run niet altijd een lus. De methode kan gewoon bestaan ​​uit enkele tientallen aanroepen naar andere methoden. Dan zou je een isInterrupted-controle moeten toevoegen voor elke methodeaanroep."

" Ten tweede kan het erg lang duren om een ​​methode uit te voeren die veel verschillende acties omvat."

" Ten derde , het gooien van een uitzondering is geen vervanging van de isInterrupted-controle. Het is gewoon een handige toevoeging. Met de gegenereerde uitzondering kun je de call-stack snel terugdraaien naar de run- methode zelf."

" Ten vierde wordt de slaapmethode veel gebruikt. Het blijkt dat deze behulpzame methode wordt versterkt door een impliciete controle die niet minder nuttig is. Het is alsof niemand de controle specifiek heeft toegevoegd, maar daar is het. Dit is super waardevol wanneer je gebruikt de code van iemand anders en je kunt de cheque niet zelf toevoegen."

" Ten vijfde , de extra controle verslechtert de prestaties niet. Het aanroepen van de slaapmethode betekent dat de thread niets zou moeten doen (behalve slapen), dus het extra werk stoort niemand."

"Dat zijn serieuze argumenten."

"En tot slot is er dit: je run-methode kan de code van iemand anders aanroepen - code waartoe je geen toegang hebt (broncode en/of rechten om de code te wijzigen). Het heeft mogelijk geen isInterrupted-controles en het kan " probeer ... catch (Exception e) " om alle exceptions te vangen."

Niemand kan garanderen dat een thread wordt gestopt. Alleen een draad kan zichzelf stoppen.