This is the second post I have on trying to end/quit threads using interrupts and dealing with Ctrl-c ends. I'm not sure I understand it but here is my best attempt. I need more clarity on the concepts, and please give code examples where you can.
There are two classes, the main class Quitit and another class thething. The main class.
When loading the program via the terminal (the case on Linux):
Java -jar Quitit.jar
When you Ctrl-c to close it am i correct in saying that you need to:
Runtime.getRuntime().addShutdownHook()
Your threads so that they are killed on shut down.
Is this to correct way to deal with that ?
Why does it not allow you to call a method so that it may close down gracefully?
When not shutting down via Ctrl-C and you wish to do so via Thread.Interrupt() then does the program below use it correctly ?
Am I correct in saying that Thread.Join() halts the calling thread until the targeted thread is dead before continuing?
How would you implement/call the same Runtime.getRuntime().addShutdownHook() on implements Runnable threads, instead of extends Thread ?
Quitit class:
public class Quitit extends Thread {
public Quitit(String name) {
try {
connect("sdfsd");
} catch (Exception ex) {
}
}
void connect(String portName) throws Exception {
Thread thh = new thething("blaghname");
Runtime.getRuntime().addShutdownHook(thh);
thh.start();
System.out.println("Thread Thh (thething) Started()");
while (true) {
try {
Thread.sleep(2000);
if (thh.isAlive()) {
System.out.println("Thread Thh (thething) isAlive");
if (thh.isInterrupted()) {
System.out.println("Thread Thh (thething) is Inturrupted Should be Shutting Down");
} else {
System.out.println("Thread Thh (thething) is Not Inturrupted");
thh.interrupt();
System.out.println("Thread Thh (thething) Inturrput Sent");
System.out.println("Thread Thh (thething) Joined()");
thh.join();
}
} else {
System.out.println("Thread Thh (thething) isDead");
System.out.println("Main Thread:: can now end After Sleep off 2 seconds");
Thread.sleep(2000);
System.out.println("MMain Thread:: Sleep Ended Calling Break");
break;
}
} catch (InterruptedException xa) {
System.out.println("Main Thread:: ending due to InterruptException second Break called");
break;
}
}
System.out.println("Main Thread:: Outside While(true) via Break call");
}
public static void main(String[] args) {
try {
Thread oop = new Quitit("");
Runtime.getRuntime().addShutdownHook(oop);
oop.start();
} catch (Exception ezx) {
System.out.println("Main Thread:: Not Expected Exception");
}
}
}
TheThing class:
public class thething extends Thread {
thething(String name) {
super(name);
}
#Override
public void run() {
while (true) {
try {
System.out.println("thething class:: Inside while(true) Loop, now sleeping for 2 seconds");
Thread.sleep(2000);
} catch (InterruptedException e) {
try {
System.out.println("thething class:: has been Inturrupted now sleeping for 2 seconds!!");
Thread.sleep(2000);
break; // Will Quit the While(true) Loop
} catch (InterruptedException ex) {
System.out.println("thething class:: Second InterruptedException called !!");
}
}
}
System.out.println("thething class:: Outside while(true) and now thread is dying");
}
}
OutPut::
run:
Thread Thh (thething) Started()
thething class:: Inside while(true) Loop, now sleeping for 2 seconds
Thread Thh (thething) isAlive
Thread Thh (thething) is Not Inturrupted
Thread Thh (thething) Inturrput Sent
Thread Thh (thething) Joined()
thething class:: has been Inturrupted now sleeping for 2 seconds!!
thething class:: Outside while(true) and now thread is dying
Thread Thh (thething) isDead
Main Thread:: can now end After Sleep off 2 seconds
MMain Thread:: Sleep Ended Calling Break
Main Thread:: Outside While(true) via Break call
FINISHED - BUILD SUCCESSFUL (total time: 8 seconds)
I am surprised to here that control-c is not killing your program. It does on my test programs and should under most Unix variants.
When you Ctrl-c to close it am i correct in saying that you need to (setup a shutdown hook) so the threads are killed on shut down.
No, this is not correct. Shutdown hooks are used when you want to explicitly cleanup up some processing. They have nothing to do with the running threads and how they terminate.
Why does it not allow you to call a method so that it may close down gracefully?
Because that's not it's job.
Is this to correct way to deal with that ?
I'm not sure what the "that" is. As others have mentioned, the JVM finishes when the last non-daemon thread finishes. At that point the JVM kills all daemon threads and exits. If you want a background thread to be killed on shutdown then you'd do something like:
Thething theThing = new TheThing();
// set it to be a daemon thread before it starts
theThing.setDaemon(true);
theThing.start();
If you are asking about the proper way to terminate a thread cleanly then you can either use a volatile boolean or interrupt the thread. Typically this means that the class that starts the thread, keeps a handle around do it. Since QuitIt started TheThing class it would do something like the following if it was using a volatile boolean:
void connect(String portName) throws Exception {
Thread thh = new TheThing("blaghname");
thh.start();
...
// we are ready to kill the thread now
tth.shutdown = true;
}
Then in TheThing, the run() method would do something like the following:
public class TheThing extends Thread {
volatile boolean shutdown = false;
public void run() {
while (!shutdown) {
...
// you can also test for shutdown while processing
if (shutdown) {
return;
}
}
}
}
When not shutting down via Ctrl-C and you wish to do so via Thread.interrupt() then does the program below use it correctly ?
Using Thread.interrupt() is another way you can signal your thread that you want it to shutdown. You can also use the thread interrupt flag in a similar manner to the boolean above:
void connect(String portName) throws Exception {
Thread thh = new TheThing("blaghname");
thh.start();
...
// we are ready to interrupt the thread now
tth.interrupt();
}
It is very important to realize that interrupting a thread sets a flag on the Thread. They thread still needs to handle the interrupt appropriately with code. Then in TheThing, the run() method would do something like the following:
public class TheThing extends Thread {
public void run() {
while (!Thread.currentThread().interrupted()) {
...
}
}
}
Interrupting also causes wait(), notify(), and other methods to throw InterruptedException. The proper way to deal with this is:
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// catching the interrupted exception clears the interrupt flag,
// so we need to re-enable it
Thread.currentThread().interrupt();
// probably you want to stop the thread if it is interrupted
return;
}
Am I correct in saying that Thread.join() halts the calling thread until the targeted thread is dead before continuing?
Yes. Calling join() (with no arguments) will pause the calling thread until the thread it is joining on finishes. So typically you set your shutdown flag or you interrupt the thread and then join with it:
tth.shutdown = true;
// or tth.interrupt()
tth.join();
How would you implement/call the same Runtime.getRuntime().addShutdownHook() on implements Runnable threads, instead of extends Thread ?
This question doesn't make any sense. If you are asking about how to shutdown a thread if you have implemented Runnable, then the same mechanisms that I mention above would work.
Another thing that factors into the discussion of control-c is signal handlers. They allow you to catch control-c (and other signals) so you can do something intelligent with them. They are very OS dependent (of course) and if you catch the interrupt signal (SIGINT is usually sent by control-c) and don't stop the JVM, you are going to have problems.
But in any case, you can do something like the following:
...
MyHandler handler = new MyHandler();
// catch the control-c signal, "TERM" is another common kill signal
Signal.handle(new Signal("INT"), handler);
...
private static class MyHandler implements SignalHandler {
#Override
public void handle(Signal arg0) {
// interrupt your threads
// clean up stuff
// set shutdown flags
// ...
}
}
Again, I would say that it is a bad practice to catch interrupt signal (control-c) and not take the JVM down.
You have many questions in your question. If you want to gracefully shutdown threads when Ctrl-C is hit, then register a shutdown hook, and in the code of this shutdown hook, gracefully shutdown your threads.
A Thread instance can be constructed by extending Thread, or by passing a Runnable to the Thread constructor. So, if you want the code of your shutdown hook to be implemented in a Runnable, just do the following:
Runnable r = new Runnable() {
#Override
public void run() {
try {
// code of the shutdown hook: ask running threads to exit gracefully
for (Thread t : threadsToShutDown) {
t.interrupt();
}
for (Thread t : threadsToShutDown) {
t.join();
}
}
catch (InterruptedException e) {
// too bad
}
}
};
Runtime.getRuntime().addShutdownHook(new Thread(r));
Note that the above will prevent the JVM to exit if one of the threads doesn't respond to the interrupt. Introducing a timeout would be a good idea.
Also note that you must NOT start the thread that you register as shutdown hook.
When you Ctrl-c to close it am i correct in saying that you need to: Runtime.getRuntime().addShutdownHook() your threads so that they are killed on shut down.
No.
As per the docs, addShutdownHook simply registers a thread that will be run when the VM is shut(-ting) down. In theory this would be used as an application-wide finalizer; something that would run when your process is ending, to "tidy up". However there are some issues with them, similar to the reasons why finalizers are not recommended, in fact. They aren't guaranteed to run if the process is terminated abruptly, so they can't do anything critical. They run at a delicate part in the lifecycle, so they may not be able to access or interact with objects in a way that you'd expect. And they need to run quickly, else risk the process being killed before they finish.
But anyway this is completely different to what you're thinking of. When the VM shuts down, your threads will exit, without you needing to.
And besides, you have to provide an unstarted thread as a shutdown hook, so I'm slightly surprised that you don't get an IllegalThreadState exception thrown on shutdown.
When not shutting down via Ctrl-C and you wish to do so via Thread.Interrupt()
That's not the "usual" way to exit a multithreaded program either.
You have (broadly) two options:
Start your threads as "daemons", then just leave them be. The program exits when no non-daemon threads are running, so when your main thread terminates, your program will exit even though your "worker" threads are still alive. This works best of course when your
Signal to your threads that they should exit, e.g. call a stop() method that sets a boolean flag, and have those threads allow themselves to terminate. A thread stops when its run() method returns. Generally threads only keep running while they're in some sort of loop. Simply letting your thread exit the ongoing loop when its told to exit will shut it down gracefully, as typically it will finish its current "chunk of work" before checking the flag.
Interrupting a thread doesn't do what you might expect. It just sets another boolean flag internally. Many blocking operations (such as filesystem/network/database methods) will periodically check this flag and throw an InterruptedException if it is set. This allows a blocking method to exit early, but is not guaranteed if the method isn't "well-behaved".
So in your example it works because Thread.sleep() does respond to interrupts, and you then consider this a signal to exit. If however you write your own method to calculate the millionth Fibonacci number, for example, interrupting the thread would do nothing unless your implementation explicitly checks Thread.currentThread().interrupted() between each iteration.
Also, interrupts can come from almost anywhere, and it's hard to ascribe a particular "meaning" to them. Are they a signal to kill the thread? A signal to give up on the current method because the client's bored? A signal to start from the top because new data has arrived? In non-trivial programs it's not entirely clear.
A much better approach, given this, is to use boolean flags to communicate the reason, and then interrupt after setting the flag. A thread that gets interrupted should then check its state to see what just happened, and work out what to do. For example, you could code thething.run() as
private boolean keepRunning = true;
public void run() {
while(keepRunning) {
try {
System.out.println("thething class:: Inside while(true) Loop, now sleeping for 2 seconds");
Thread.sleep(2000);
} catch (InterruptedException e) {
try {
System.out.println("thething class:: has been Inturrupted now sleeping for 2 seconds!!");
Thread.sleep(2000);
} catch (InterruptedException ex)
{
System.out.println("thething class:: Second InterruptedException called !!");
}
}
}
}
And in QuitIt, set thh.keepRunning = false before interrupting it (or even better, define a method such as thh.allWorkDone() which sets the flag, and call that).
Note that there is no way to forcibly stop another thread - with good reason - you need to signal for the thread to stop, and ensure that whatever's running in the thread observes and respects that signal.
Best by huge margin - use daemon threads with no explicit termination. Next, redesign app so I can use daemon threads with no explicit termination. Absolute last resort, when no other approach is remotely possible, any kind of explicit shutdown code such has been posted here.
Related
I wrote a thread, it is taking too much time to execute and it seems it is not completely done. I want to stop the thread gracefully. Any help ?
The good way to do it is to have the run() of the Thread guarded by a boolean variable and set it to true from the outside when you want to stop it, something like:
class MyThread extends Thread
{
volatile boolean finished = false;
public void stopMe()
{
finished = true;
}
public void run()
{
while (!finished)
{
//do dirty work
}
}
}
Once upon a time a stop() method existed but as the documentation states
This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior.
That's why you should have a guard..
The bad part about using a flag to stop your thread is that if the thread is waiting or sleeping then you have to wait for it to finish waiting/sleeping. If you call the interrupt method on the thread then that will cause the wait or sleep call to be exited with an InterruptedException.
(A second bad part about the flag approach is that most nontrivial code is going to be utilizing libraries like java.util.concurrent, where the classes are specifically designed to use interruption to cancel. Trying to use the hand rolled flag in a task passed into an Executor is going to be awkward.)
Calling interrupt() also sets an interrupted property that you can use as a flag to check whether to quit (in the event that the thread is not waiting or sleeping).
You can write the thread's run method so that the InterruptedException is caught outside whatever looping logic the thread is doing, or you can catch the exception within the loop and close to the call throwing the exception, setting the interrupt flag inside the catch block for the InterruptedException so that the thread doesn't lose track of the fact that it was interrupted. The interrupted thread can still keep control and finish processing on its own terms.
Say I want to write a worker thread that does work in increments, where there's a sleep in the middle for some reason, and I don't want quitting the sleep to make processing quit without doing the remaining work for that increment, I only want it to quit if it is in-between increments:
class MyThread extends Thread
{
public void run()
{
while (!Thread.currentThread().isInterrupted())
{
doFirstPartOfIncrement();
try {
Thread.sleep(10000L);
} catch (InterruptedException e) {
// restore interrupt flag
Thread.currentThread().interrupt();
}
doSecondPartOfIncrement();
}
}
}
Here is an answer to a similar question, including example code.
You should not kill Thread from other one. It's considered as fairly bad habit. However, there are many ways. You can use return statement from thread's run method.
Or you can check if thread has already been interrupted and then it will cancel it's work. F.e. :
while (!isInterrupted()) {
// doStuff
}
Make a volatile boolean stop somewhere. Then in the code that runs in the thread, regularly do
if (stop) // end gracefully by breaking out of loop or whatever
To stop the thread, set stop to true.
I think you must do it manually this way. After all, only the code running in the thread has any idea what is and isn't graceful.
You need to send a stop-message to the Thread and the Thread itself needs to take action if the message has been received. This is pretty easy, if the long-running action is inside loop:
public class StoppableThread extends Thread {
private volatile boolean stop = false;
public void stopGracefully() {
stop = true;
}
public void run() {
boolean finished = false;
while (!stop && !finished) {
// long running action - finished will be true once work is done
}
}
}
For a thread to stop itself, no one seems to have mentioned (mis)using exception:
abstract class SelfStoppingThread extends Thread {
#Override
public final void run() {
try {
doRun();
} catch (final Stop stop) {
//optional logging
}
}
abstract void doRun();
protected final void stopSelf() {
throw new Stop();
}
private static final class Stop extends RuntimeException {};
}
A subclass just need to override doRun() normally as you would with a Thread, and call stopSelf() whenever it feels like it wants to stop. IMO it feels cleaner than using a flag in a while loop.
I want to achieve the following: When my application starts, the main thread will start 1+ worker threads that should run in the background, and periodically do things behind the scenes. These should not block the main thread: once main starts the workers, it continues doing its own thing until:
The main thread finishes (normal application termination) - in the case of a command-line utility this is when the end of the main(String[]) method is reached; in the case of a Swing GUI it could be when the user selects the File >> Exit menu, etc.
The operating system throws a kill command (SIGKILL, etc.)
An unexpected, uncaught exception occurs in the main thread, effectively killing it (this is just an unpolite version of #1 above)
Once started/submitted from the main thread, I want all the worker threads (Runnables) to essentially have their own life cycle, and exist independently of the main thread. But, if the main thread dies at any time, I want to be able to block (if at all possible) the main thread until all the workers are finished shutting down, and then "allow" the main thread to die.
My best attempt so far, although I know I'm missing pieces here and there:
public class MainDriver {
private BaneWorker baneWorker;
private ExecutorService executor = Executors.newCachedThreadPool();
public static void main(String[] args) {
MainDriver driver = new MainDriver();
driver.run();
// We've now reached the end of the main method. All workers should block while they shutdown
// gracefully (if at all possible).
if(executor.awaitTermination(30, TimeUnit.SECONDS))
System.out.println("Shutting down...");
else {
System.out.println("Forcing shut down...");
executor.shutdownNow();
}
}
private void run() {
// Start all worker threads.
baneWorker = new BaneWorker(Thread.currentThread());
// More workers will be used once I get this simple example up and running...
executor.submit(baneWorker);
// Eventually submit the other workers here as well...
// Now start processing. If command-line utility, start doing whatever the utility
// needs to do. If Swing GUI, fire up a parent JFrame and draw the application to the
// screen for the user, etc.
doStuff();
}
private void doStuff() {
// ??? whatever
}
}
public class BaneWorker implements Runnable {
private Timer timer;
private TimerTask baneTask;
private Thread mainThread;
public BaneWorker(Thread mainThread) {
super();
this.mainThread = mainThread;
}
#Override
public void run() {
try {
timer = new Timer();
baneTask = new TimerTask() {
#Override
public void run() {
System.out.println("When the main thread is ashes...");
}
};
// Schedule the baneTask to kick off every minute starting now.
timer.scheduleAtFixedRate(baneTask, new Date(), 60 * 1000);
} catch(InterruptedException interrupt) {
// Should be thrown if main thread dies, terminates, throws an exception, etc.
// Should block main thread from finally terminating until we're done shutting down.
shutdown();
}
}
private void shutdown() {
baneTask.cancel();
System.out.println("...then you have my permission to die.");
try {
mainThread.join();
} catch(InterruptedException interrupt) {
interrupt.printStackTrace;
}
}
}
Am I on-track or way off-base here? What do I need to change to make this work the way I need it to? I'm new to Java concurrency and am trying my best to use the Concurrency API correctly, but stumbling around a bit. Any ideas? Thanks in advance!
The main thread must signal the worker threads to terminate (generally this is achieved just by using a flag) and then it should call join on every thread to wait for their termination. Have a look here: Java: How to use Thread.join
You can use Runtime.addShutdownHook to register an un-started thread that is executed when a JVM is terminated, the system is shutting down etc. This code can do some cleanup itself, or perhaps notify running daemon threads to finish their work. Any such cleanup code must be relatively fast, because on many systems programs have only a limited time to do cleanup before they're forcibly terminated.
Perhaps you could also consider making your background thread daemon threads. Then they will not block the JVM when main finishes and will be still running during the clean-up phase.
Note that you can't intercept SIGKILL - this signal is designed to be unavoidable and immediate. But it should work with SIGTERM, SIGHUP and similar signals.
Update: You can easily create ExecutorServices that run daemon threads. All you need is to create a proper ThreadFactory:
public static class DaemonFactory
implements ThreadFactory
{
#Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r);
t.setDaemon(true);
return t;
}
}
than you create an ExecutorService like
public static void main(String argv[])
throws Exception
{
ExecutorService es
= Executors.newCachedThreadPool(new DaemonFactory());
// ^^^^^^^^^^^^^^^^^^^
es.submit(new Callable<Object>() {
public Object call() throws Exception {
Thread.sleep(100);
System.err.println("Daemon: " +
Thread.currentThread().isDaemon());
return null;
}
});
// Without this, JVM will terminate before the daemon thread prints the
// message, because JVM doesn't wait for daemon threads when
// terminating:
es.awaitTermination(3, TimeUnit.SECONDS);
}
Concerning Thread.join(), you shouldn't try to use it on threads managed by an ExecutorService. It's the responsibility of the executor to manage them. You have no reliable way how to enumerate its threads, the executor can create and destroy threads depending on its configuration etc. The only reliable way is to call shutdown(); and then awaitTermination(...);.
If SIGKILL is a unix "kill -9" there's nothing you can do about it.
For graceful exits, use a try/catch/finally in your main. The catch will catch your exceptions and allow you to do what needs to be done (recover? abort?) The finally will give you the hook to spin down your threads gracefully.
Reviewing your code quickly, I don't see where you're keeping track of your thread instances. You'll need those if you're going to tell them to spin down.
psuedocode:
static Main(...) {
ArrayList threads = new ArrayList();
try {
for (each thread you want to spin up) {
threads.add(a new Thread())
}
}
catch { assuming all are fatal. }
finally {
for(each thread t in threads) {
t.shutdown();
t.join(); /* Be prepared to catch (and probably ignore) an exception on this, if shutdown() happens too fast! */
}
}
Is it sufficient to wrap contents of run method inside a while loop that checks if THread is interrupted for making any Thread interruptable
public void run () {
while (!Thread.interrupted()) {
do something.
}
}
How does a thread support its own interruption? This depends on what
it's currently doing. If the thread is frequently invoking methods
that throw InterruptedException, it simply returns from the run method
after it catches that exception.
Reference documentation
For a example if your thread goes for sleep bettween work then it is better to catch InterruptedException.
public void run(){
while(true)
try {
Thread.sleep(4000);
} catch (InterruptedException e) {
// We've been interrupted: no more messages.
return;
}
}
If your thread runs for long time you can check periodically invoke Thread.interrupted, which returns true if an interrupt has been received.
interrupted() is static method to check the current thread is interrupted or not. isInterrupted() is an instance to check the Thread objects called on.
For Present Thread use
if(!(Thread.interrupted())){//do something}
When Thread object called use if(myThread.isInterrupted()){//do something
}
I am new to Java/threads and I inherited something like the following code. It is a command line program that main() only starts 5-6 different kind of threads and exits with ^C. I want to add a shutdown hook to close all threads properly and adapted it the following way.
I added a Shutdown hook and a stopThread() method in all threads (like the one in MyWorker class)
The problem is that when I press ^C I don't see the end message from the Thread's run method. Is this done in the background or is there something wrong with my method. Also, Is there a better pattern I should follow?
Thanks
public class Main {
public static MyWorker worker1 = new MyWorker();
// .. various other threads here
public static void startThreads() {
worker1.start();
// .. start other threads
}
public static void stopThreads() {
worker1.stopThread();
// .. stop other threads
}
public static void main(String[] args)
throws Exception {
startThreads();
// TODO this needs more work (later)
Runtime.getRuntime().addShutdownHook(new Thread() {
#Override
public void run() {
try {
stopThreads();
} catch (Exception exp) {
}
}
});
} }
public class MyWorker extends Thread {
private volatile boolean stop = false;
public void stopThread() {
stop = true;
}
public void run() {
while (!stop) {
// Do stuff here
}
// Print exit message with logger
}
}
Shutdown Hooks may not be executed in some cases!
First thing to keep in mind is that it is not guaranteed that shutdown hooks will always run. If the JVM crashes due to some internal error, then it might crash down without having a chance to execute a single instruction.
Also, if the O/S gives a SIGKILL (http://en.wikipedia.org/wiki/SIGKILL) signal (kill -9 in Unix/Linux) or TerminateProcess (Windows), then the application is required to terminate immediately without doing even waiting for any cleanup activities. In addition to the above, it is also possible to terminate the JVM without allowing the shutdown hooks to run by calling Runime.halt() method.
Shutdown hooks are called when the application terminates normally (when all threads finish, or when System.exit(0) is called). Also, when the JVM is shutting down due to external causes such as user requesting a termination (Ctrl+C), a SIGTERM being issued by O/S (normal kill command, without -9), or when the operating system is shutting down.
When you call System.exit() or terminate via a signal, it stop all the existing threads and starts all the shutdown hooks. i.e. all your threads could be dead by the time you hook starts.
Instead of trying to stop threads cleanly, you should ensure resources are closed cleanly.
I guess you can shift your code to ExecutorService
private final ExecutorService pool;
pool = Executors.newFixedThreadPool(poolSize);
pool.execute(Instance of Runnable);
pool.shutdown();
ExecutorService.shutdown
Initiates an orderly shutdown in which previously submitted tasks are executed, but no new tasks will be accepted. Invocation has no additional effect if already shut down.
Try making your threads as daemon threads.
Add a constructor
public MyWorker(boolean isDaemon) {
this.setDaemon(true);
}
or set to daemon before calling start.
worker1.setDaemon(true);
worker1.start();
When you press Ctrl C and exit, the threads will be stopped.
What is happening here is that you invoke the stopThread() method, but you don't wait the the threads are actually finished before terminating.
If you invoke a join() on all threads before stoping the JVM, you will probably see your 'stop logs'.
public static void stopThreads() {
worker1.stopThread();
// .. stop other threads
for(Thread t: workers) {
t.join();
}
}
Thread currentThread=Thread.currentThread();
public void run()
{
while(!shutdown)
{
try
{
System.out.println(currentThread.isAlive());
Thread.interrupted();
System.out.println(currentThread.isAlive());
if(currentThread.isAlive()==false)
{
shutdown=true;
}
}
catch(Exception e)
{
currentThread.interrupt();
}
}
}
});
thread.start();
The alternative to calling stop is to use interrupt to signal to the thread that you want it to finish what it's doing. (This assumes the thread you want to stop is well-behaved, if it ignores InterruptedExceptions by eating them immediately after they are thrown and doesn't check the interrupted status then you are back to using stop().)
Here's some code I wrote as an answer to a threading question here, it's an example of how thread interruption works:
public class HelloWorld {
public static void main(String[] args) throws Exception {
Thread thread = new Thread(new Runnable() {
public void run() {
try {
while (!Thread.currentThread().isInterrupted()) {
Thread.sleep(5000);
System.out.println("Hello World!");
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
});
thread.start();
System.out.println("press enter to quit");
System.in.read();
thread.interrupt();
}
}
Some things to be aware of:
Interrupting causes sleep() and wait() to immediately throw, otherwise you are stuck waiting for the sleep time to pass.
Note that there is no need for a separate boolean flag.
The thread being stopped cooperates by checking the interrupted status and catching InterruptedExceptions outside the while loop (using it to exit the loop). Interruption is one place where it's ok to use an exception for flow control, that is the whole point of it.
Setting interrupt on the current thread in the catch block is technically best-practice but is overkill for this example, because there is nothing else that needs the interrupt flag set.
Some observations about the posted code:
The posted example is incomplete, but putting a reference to the current thread in an instance variable seems like a bad idea. It will get initialized to whatever thread is creating the object, not to the thread executing the run method. If the same Runnable instance is executed on more than one thread then the instance variable won't reflect the right thread most of the time.
The check for whether the thread is alive is necessarily always going to result in true (unless there's an error where the currentThread instance variable is referencing the wrong thread), Thread#isAlive is false only after the thread has finished executing, it doesn't return false just because it's been interrupted.
Calling Thread#interrupted will result in clearing the interrupt flag, and makes no sense here, especially since the return value is discarded. The point of calling Thread#interrupted is to test the state of the interrupted flag and then clear it, it's a convenience method used by things that throw InterruptedException.
Typically, a thread is terminated when it's interrupted. So, why not use the native boolean? Try isInterrupted():
Thread t = new Thread(new Runnable(){
#Override
public void run() {
while(!Thread.currentThread().isInterrupted()){
// do stuff
}
}});
t.start();
// Sleep a second, and then interrupt
try {
Thread.sleep(1000);
} catch (InterruptedException e) {}
t.interrupt();
Good way to do it would be to use a boolean flag to signal the thread.
class MyRunnable implements Runnable {
public volatile boolean stopThread = false;
public void run() {
while(!stopThread) {
// Thread code here
}
}
}
Create a MyRunnable instance called myrunnable, wrap it in a new Thread instance and start the instance. When you want to flag the thread to stop, set myrunnable.stopThread = true. This way, it doesn't get stopped in the middle of something, only where we expect it to get stopped.