Why Is Thread.stop Deprecated?

Thread.stop is deprecated because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his or her program may be cor-rupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

Could I Catch the ThreadDeath Exception and Fix the Damaged Object?

In theory, perhaps, but it would vastly complicate the task of writing correct multithreaded code. The task would be nearly insurmountable for two reasons:

1. A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind.
2. A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated until it succeeded. The code to ensure this would be quite complex.

In sum, it just isn't practical.

What about Thread.stop(Throwable)?

In addition to all the problems noted previously, this method may be used to generate exceptions that its target thread is unprepared to handle, including checked exceptions that the thread could not possibly throw, were it not for this method. For example, the following method is behaviorally identical to Java's throw operation but circumvents the compiler's attempts to guarantee that the calling method has declared all the checked exceptions that it may throw:

static void sneakyThrow(Throwable t) { 
 Thread.currentThread().stop(t); 
} 

What Should I Use Instead of Thread.stop?

Most uses of stop should be replaced by code that simply modifies a variable to indicate that the target thread should stop running. The target thread should check this variable regularly and return from its run method in an orderly fashion if the variable indicates that it is to stop running. This is the approach recommended in the chapter Threads: Doing Two or More Tasks at Once (page 269). To ensure prompt communication of the stop request, the variable must be volatile, or access to the variable must be synchronized.

For example, suppose that your applet contains the following start, stop, and run methods:

private Thread blinker; 

public void start() { 
 blinker = new Thread(this); 
 blinker.start(); 
} 

public void stop() { 
 blinker.stop(); // UNSAFE! 
} 
public void run() { 
 Thread thisThread = Thread.currentThread(); 
 while (true) { 
 try { 
 thisThread.sleep(interval); 
 } catch (InterruptedException e){ 
 } 
 repaint(); 
 } 
} 

You can avoid the use of Thread.stop by replacing the applet's stop and run methods with:

private volatile Thread blinker; 

public void stop() { 
 blinker = null; 
} 

public void run() { 
 Thread thisThread = Thread.currentThread(); 
 while (blinker == thisThread) { 
 try { 
 thisThread.sleep(interval); 
 } catch (InterruptedException e){ 
 } 
 repaint(); 
 } 
} 

How Do I Stop a Thread That Waits for Long Periods?

That's what the Thread.interrupt method is for. The same "state-based" signaling mechanism shown previously can be used, but the state change (blinker = null, in the previous example) can be followed by a call to Thread.interrupt to interrupt the wait:

public void stop() { 
 Thread moribund = waiter; 
 waiter = null; 
 moribund.interrupt(); 
} 

For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say reasserts rather than rethrows because it is not always possible to rethrow the exception. If the method that catches the InterruptedException is not declared to throw this (checked) exception, it should "reinterrupt itself" with the following incantation:

Thread.currentThread().interrupt(); 

This ensures that the Thread will raise the InterruptedException again as soon as it is able.

What If a Thread Doesn't Respond to Thread.interrupt?

In some cases, you can use application-specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general. It should be noted that in all situations in which a waiting thread doesn't respond to Thread.interrupt , it wouldn't respond to Thread.stop , either. Such cases include deliberate denial-of-service attacks and I/O operations for which thread.stop and thread.interrupt do not work properly.