"Olá, amigo! Você tem que admitir que a ideia de Cancelar de Ellie foi brilhante."

"Sim."

"Na verdade, existe algo semelhante na classe Thread . Só que a variável não se chama isCancel . Chama-se isInterrupt . E o método usado para parar a thread não é cancel() . É interrupt() ."

"Realmente?"

"Sim. Confira:"

Código Descrição 
class Clock implements Runnable
{
public void run()
{
Thread current = Thread.currentThread();

while (!current.isInterrupted())
{
Thread.sleep(1000);
System.out.println("Tick");
}
}
}
 Como vários threads podem chamar o método run no mesmo objeto Clock, obtemos o objeto Thread para o thread atual .

A classe Clock grava a palavra "Tick" no console uma vez por segundo, desde que a variável isInterrupt do thread atual seja falsa.

Quando isInterrupt se torna true , o método run  termina.

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

Thread.sleep(10000);
clockThread.interrupt();
}
 O thread principal inicia um thread filho (relógio) que deve ser executado para sempre.

Aguarde 10 segundos e  cancele a tarefa chamando o método de interrupção .

O thread principal conclui seu trabalho.

O thread do relógio termina seu trabalho.
Java webinar

Além disso, o método sleep , que as pessoas gostam tanto de usar em loops infinitos no método run , verifica automaticamente a variável isInterrupt . Se um thread chamar o método sleep , o método primeiro verificará se isInterrupt é verdadeiro para esse thread. Se for verdadeiro, o método não dormirá. Em vez disso, ele lança uma exceção InterruptedException .

"Por que lançar uma exceção? Não seria melhor simplesmente colocar isInterrupted() em vez de isCancel() em um loop?"

" Primeiro , o método run nem sempre tem um loop. O método pode simplesmente consistir em algumas dezenas de chamadas para outros métodos. Então você teria que adicionar uma verificação isInterrupted antes de cada chamada de método."

" Em segundo lugar , alguns métodos que envolvem muitas ações diferentes podem levar muito tempo para serem executados."

" Terceiro , lançar uma exceção não substitui a verificação isInterrupted. É apenas uma adição conveniente. A exceção lançada permite que você desfaça rapidamente a pilha de chamadas de volta ao próprio método run ."

" Em quarto lugar , o método de suspensão é muito usado. Acontece que esse método útil é aprimorado por uma verificação implícita que não é menos útil. É como se ninguém especificamente tivesse adicionado a verificação, mas aí está. Isso é super valioso quando você está usando o código de outra pessoa e não pode adicionar a verificação sozinho."

" Quinto , a verificação adicional não degrada o desempenho. Chamar o método sleep significa que o thread não deve fazer nada (exceto dormir), então o trabalho extra não incomoda ninguém."

"Esses são argumentos sérios."

"E, finalmente , há isto: seu método run pode chamar o código de outra pessoa - código ao qual você não tem acesso (código-fonte e/ou direitos para alterar o código). Ele pode não ter verificações isInterrupted e pode usar " try ... catch (Exception e) " para capturar todas as exceções."

Ninguém pode garantir que um thread será interrompido. Apenas um thread pode parar a si mesmo.