Java stop waiting thread

Different Ways to Kill a Thread in Java

There is no official method to kill a thread in Java. Stopping a thread is entirely managed by the JVM. Although Java provides several ways to manage the thread lifecycle such as a start(), sleep(), stop() (deprecated in Java 1.1), etc. but does not provide any method to kill a thread and free the resources cleanly.

Oracle specified the reason for deprecating the stop() method as It is inherently unsafe. Stopping a thread causes it to unlock all its locked monitors.

1. Two Ways to Kill a Thread

Effectively, we can only signal the thread to stop itself and let the thread clean up the resources and terminate itself. In Java, we can send a signal to a thread in two ways:

• By periodically checking a boolean flag
• By interrupting the thread using Thread.interrupt() method

Let us learn about both methods:

In this method, we check a boolean flag periodically, or after every step in the task. Initially, the flag is set to false. To stop the thread, set the flag to true. Inside the thread, when the code checks the flag’s value to true, it destroys itself gracefully and returns.

Note that in this design, generally, there are two threads. One thread sets the flag value to true, and another thread checks the flag value. To ensure that both threads see the same value all the time, we must make the flag variable volatile. Or we can use AtomicBoolean class that supports atomic operations on an underlying volatile boolean variable.

public class CustomTask implements Runnable < private volatile boolean flag = false; private Thread worker; public void start() < worker = new Thread(this); worker.start(); >public void stop() < flag = true; >@Override public void run() < while (!flag) < try < Thread.sleep(500); System.out.println(Thread.currentThread().getName() + " Running. "); >catch (InterruptedException e) < Thread.currentThread().interrupt(); System.out.println("Thread was interrupted," + e.getMessage()); >> System.out.println(Thread.currentThread().getName() + " Stopped"); return; > >

Let us test this design by creating two threads and stopping them.

CustomTask task1 = new CustomTask(); CustomTask task2 = new CustomTask(); task1.start(); task2.start(); try < Thread.sleep(1000); task1.stop(); task2.stop(); >catch (InterruptedException e)

Thread-0 Running. Thread-1 Running. Thread-1 Running. Thread-0 Running. Thread-1 Stopped Thread-0 Stopped

3. By Interrupting the Thread

This method is also very similar to the previous approach of using a flag. The only difference is that we will interrupt the thread instead of setting the flag to false.

So inside the thread, we will keep checking the thread’s interrupt status, and when the thread is interrupted, we will stop the thread gracefully. To check the status of the interrupted thread, we can use the Thread.isInterrupted() method. It returns either true or false based on the thread’s interrupt status.

public class CustomTaskV2 implements Runnable < private Thread worker; public void start() < worker = new Thread(this); worker.start(); >public void interrupt() < worker.interrupt(); >@Override public void run() < while (!Thread.currentThread().isInterrupted()) < try < Thread.sleep(500); System.out.println(Thread.currentThread().getName() + " Running. "); >catch (InterruptedException e) < Thread.currentThread().interrupt(); System.out.println("Thread was interrupted with reason : " + e.getMessage()); >> System.out.println(Thread.currentThread().getName() + " Stopped"); return; > >

Interestingly, the code to test this design is similar to the previous one. Only the method call to thread.interrupt() is additional.

CustomTaskV2 task1 = new CustomTaskV2(); CustomTaskV2 task2 = new CustomTaskV2(); task1.start(); task2.start(); try < Thread.sleep(1100);isInterrupted task1.interrupt(); task2.interrupt(); >catch (InterruptedException e)

Thread-0 Running. Thread-1 Running. Thread-1 Running. Thread-0 Running. Thread was interrupted with reason : sleep interrupted Thread was interrupted with reason : sleep interrupted Thread-0 Stopped Thread-1 Stopped

This tutorial taught us to kill a running thread in Java using custom solutions. Even though the boolean flag solution is very good, it may not give the desired result for long-running tasks where the thread is waiting most of the time.

Sending an interrupt is a much better approach to stop a long-waiting thread.

Источник

Java stop waiting thread

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 program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

Couldn’t I just 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 till it succeeded. The code to ensure this would be quite complex.

What about Thread.stop(Throwable) ?

In addition to all of the problems noted above, 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 of the checked exceptions that it may throw:

static void sneakyThrow(Throwable t)

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 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() < while (true) < try < Thread.sleep(interval); >catch (InterruptedException e) < >repaint(); > >

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) < >repaint(); > >

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:

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();

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.

Why are Thread.suspend and Thread.resume deprecated?

Thread.suspend is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling resume , deadlock results. Such deadlocks typically manifest themselves as «frozen» processes.

What should I use instead of Thread.suspend and Thread.resume ?

As with Thread.stop , the prudent approach is to have the «target thread» poll a variable indicating the desired state of the thread (active or suspended). When the desired state is suspended, the thread waits using Object.wait . When the thread is resumed, the target thread is notified using Object.notify .

For example, suppose your applet contains the following mousePressed event handler, which toggles the state of a thread called blinker :

private boolean threadSuspended; Public void mousePressed(MouseEvent e) < e.consume(); if (threadSuspended) blinker.resume(); else blinker.suspend(); // DEADLOCK-PRONE! threadSuspended = !threadSuspended; >

public synchronized void mousePressed(MouseEvent e)

The wait method throws the InterruptedException , so it must be inside a try . catch clause. It’s fine to put it in the same clause as the sleep . The check should follow (rather than precede) the sleep so the window is immediately repainted when the thread is «resumed.» The resulting run method follows:

public void run() < while (true) < try < Thread.sleep(interval); synchronized(this) < while (threadSuspended) wait(); >> catch (InterruptedException e) < >repaint(); > >

Note that the notify in the mousePressed method and the wait in the run method are inside synchronized blocks. This is required by the language, and ensures that wait and notify are properly serialized. In practical terms, this eliminates race conditions that could cause the «suspended» thread to miss a notify and remain suspended indefinitely.

While the cost of synchronization in Java is decreasing as the platform matures, it will never be free. A simple trick can be used to remove the synchronization that we’ve added to each iteration of the «run loop.» The synchronized block that was added is replaced by a slightly more complex piece of code that enters a synchronized block only if the thread has actually been suspended:

In the absence of explicit synchronization, threadSuspended must be made volatile to ensure prompt communication of the suspend-request.

The resulting run method is:

private volatile boolean threadSuspended; public void run() < while (true) < try < Thread.sleep(interval); if (threadSuspended) < synchronized(this) < while (threadSuspended) wait(); >> > catch (InterruptedException e) < >repaint(); > >

Can I combine the two techniques to produce a thread that may be safely «stopped» or «suspended»?

Yes, it’s reasonably straightforward. The one subtlety is that the target thread may already be suspended at the time that another thread tries to stop it. If the stop method merely sets the state variable (blinker) to null, the target thread will remain suspended (waiting on the monitor), rather than exiting gracefully as it should. If the applet is restarted, multiple threads could end up waiting on the monitor at the same time, resulting in erratic behavior.

To rectify this situation, the stop method must ensure that the target thread resumes immediately if it is suspended. Once the target thread resumes, it must recognize immediately that it has been stopped, and exit gracefully. Here’s how the resulting run and stop methods look:

public void run() < Thread thisThread = Thread.currentThread(); while (blinker == thisThread) < try < Thread.sleep(interval); synchronized(this) < while (threadSuspended && blinker==thisThread) wait(); >> catch (InterruptedException e) < >repaint(); > > public synchronized void stop()

If the stop method calls Thread.interrupt, as described above, it needn’t call notify as well, but it still must be synchronized. This ensures that the target thread won’t miss an interrupt due to a race condition.

What about Thread.destroy ?

Thread.destroy was never implemented and has been deprecated. If it were implemented, it would be deadlock-prone in the manner of Thread.suspend . (In fact, it is roughly equivalent to Thread.suspend without the possibility of a subsequent Thread.resume .)

Why is Runtime.runFinalizersOnExit deprecated?

Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to «defend against» this call, most programmers do not defend against it. They assume that an object is dead at the time that its finalizer is called.

Further, the call is not «thread-safe» in the sense that it sets a VM-global flag. This forces every class with a finalizer to defend against the finalization of live objects!

Источник