"¡Hola, amigo! Tienes que admitir que la idea de cancelar de Ellie fue brillante".

"Sí."

"En realidad, existe algo similar en la clase Thread . Solo que la variable no se llama isCancel . Se llama isInterrupt . Y el método utilizado para detener el hilo no es cancel() . Es interrupt() ".

"¿En realidad?"

"Sí. Compruébalo:"

Código Descripción 
class Clock implements Runnable
{
public void run()
{
Thread current = Thread.currentThread();

while (!current.isInterrupted())
{
Thread.sleep(1000);
System.out.println("Tick");
}
}
}
 Debido a que varios subprocesos pueden llamar al método de ejecución en el mismo objeto Reloj, obtenemos el objeto Subproceso para el subproceso actual .

La clase Clock escribe la palabra "Tick" en la consola una vez por segundo, siempre que la variable isInterrupt del subproceso actual sea falsa.

Cuando isInterrupt se vuelve verdadero , el método de ejecución  finaliza.

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

Thread.sleep(10000);
clockThread.interrupt();
}
 El subproceso principal inicia un subproceso secundario (reloj) que debe ejecutarse para siempre.

Espere 10 segundos y  cancele la tarea llamando al método de interrupción .

El hilo principal completa su trabajo.

El hilo del reloj termina su trabajo.
Java university

Además, el método de suspensión , que a la gente le gusta usar en bucles interminables en el método de ejecución , verifica automáticamente la variable isInterrupt . Si un subproceso llama al método de suspensión , el método primero verifica si isInterrupt es verdadero para ese subproceso. Si es cierto, el método no dormirá. En su lugar, lanza una excepción InterruptedException .

"¿Por qué lanzar una excepción? ¿No sería mejor simplemente poner isInterrupted() en lugar de isCancel() en un bucle?"

" Primero , el método de ejecución no siempre tiene un bucle. El método podría consistir simplemente en unas pocas docenas de llamadas a otros métodos. Luego, tendría que agregar una verificación isInterrupted antes de cada llamada al método".

" En segundo lugar , algunos métodos que implican muchas acciones diferentes pueden tardar mucho tiempo en ejecutarse".

" Tercero , lanzar una excepción no reemplaza la verificación isInterrupted. Es solo una adición conveniente. La excepción lanzada le permite deshacer rápidamente la pila de llamadas al método de ejecución en sí".

En cuarto lugar , el método de suspensión se usa mucho. Resulta que este útil método se ve mejorado por una verificación implícita que no es menos útil. Es como si nadie hubiera agregado específicamente la verificación, pero ahí está. Esto es muy valioso cuando está utilizando el código de otra persona y no puede agregar el cheque usted mismo".

" En quinto lugar , la verificación adicional no degrada el rendimiento. Llamar al método de suspensión significa que el subproceso no debería hacer nada (excepto dormir), por lo que el trabajo adicional no molesta a nadie".

"Esos son argumentos serios".

"Y, finalmente , está esto: su método de ejecución puede llamar al código de otra persona, código al que no tiene acceso (código fuente y/o derechos para cambiar el código). Es posible que no tenga verificaciones isInterrupted, y podría usar " Try ... catch (Exception e) " para capturar todas las excepciones.

Nadie puede garantizar que se detendrá un hilo. Sólo un hilo puede detenerse a sí mismo.