# Java Thread Primitive Deprecation

## Why is `Thread.stop` deprecated and the ability to stop a thread removed?

Because it was inherently unsafe. Stopping a thread caused it to unlock all the monitors that it had locked. (The monitors were unlocked as the `ThreadDeath` exception propagated up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may have viewed 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` killed threads silently; thus, the user had no warning that their program may be corrupted. The corruption could manifest itself at any time after the actual damage occurs, even hours or days in the future.

## Couldn't I have just caught `ThreadDeath` and fixed 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 could 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 could throw a second `ThreadDeath` exception while cleaning up from the first (in the `catch` or `finally` clause). Cleanup would have to be repeated till it succeeded. The code to ensure this would be quite complex.

In sum, it just isn't practical.

## What should I use instead of `Thread.stop`?

Most uses of `stop` should be replaced by code that simply modifies some 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. To ensure prompt communication of the stop-request, the variable must be `volatile` (or access to the variable must be synchronized).

For example, suppose your application 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() {
            while (true) {
                try {
                    Thread.sleep(interval);
                } catch (InterruptedException e){
                }
                blink();
            }
        }

You can avoid the use of `Thread.stop` by replacing the application'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 {
                    Thread.sleep(interval);
                } catch (InterruptedException e){
                }
                blink();
            }
        }

## How do I stop a thread that waits for long periods (e.g., for input)?

That's what the `Thread.interrupt` method is for. The same "state based" signaling mechanism shown above 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, then it should "reinterrupt itself" with the following incantation:

        Thread.currentThread().interrupt();

This ensures that the Thread will reraise the `InterruptedException` 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 where 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.