How to stop a Thread in Java ?

[Rohit Kumar Singh]

As far as I know, stop() method in Thread class is deprecated..

My question is if theres no way to stop a thread in Java then how to stop a thread in java ?

[Campbell Ritchie]

Don't you have some sort of while loop inside your thread? Put the entire contents of the thread inside a while, and when you want to stop, change the loop condition to false. Then all the methods will complete normally. There are examples of threads using loops in the Java Tutorials.

[Rohit Kumar Singh]

That is ok sir... but exactly what i am asking is that, what if i want to kill my thread externally, suppose my program is accepting packet's from network and it's executing accordingly , at some point of time i want to stop that thread ..

In a Nutshell, what if i exclusively want to kill a particular Thread.

How to do that ??

[Campbell Ritchie]

Don't know. Anybody else?
Maybe if something has gone wrong with your packages you should be throwing an Exception.
Maybe you should have a method which stops accepting packages, then the thread will shut down cleanly.

[Keith Lynn]

One suggestion I would have is a mutator method in the class that sets the value of the variable that controls the loop in your thread.

[Rohit Kumar Singh]

Please go through this link once.


Actually at the first place, i didn't understand, why stop() method is deprecated.

i have gone through the above link , but unable to get it completely.


can anybody tell the reason after going through this link or by your own .

[Chan Ag]

One thing you could do is have safe checkpoints in your code at which point you could check if an interrupt was received. If so, you could have the logic to return gracefully.

Why would you want to kill a thread? For one thing, you wouldn't know what state the critical resources are in, what monitors are held, and so on.. You would definitely have planned it before hand, I assume.

Also I think if you are using an ExecutorService implementation, you could always issue a shutdown or a shutdownNow.

I assume you've read why the stop method is deprecated and what makes it difficult/impractical to catch the ThreadDeath error and fix the damaged object?

[Jayesh A Lalwani]

What don't you understand from that link? It says that objects might be damaged on stop. Do you want to know why objects might be damaged?

[Rohit Kumar Singh]

Jayesh A Lalwani wrote:What don't you understand from that link? It says that objects might be damaged on stop. Do you want to know why objects might be damaged?

Yes, I want to know why stop() method is Deprecated??

what is the meaning of Damaged object ?

How stopping a Thread will put object into an unstable state ?

[Ulf Dittmer]

How stopping a Thread will put object into an unstable state ?

Let's be precise: Stopping a thread doesn't put any object into an unusable state - using Thread.stop() does that. Stopping a thread as suggested above is fine. While it's good to be curious, in this particular case I would just accept that you should not use those methods and move on. The explanation is highly technical, and won't make sense unless you know the internals of the JVM very well (very few people do).

[Chan Ag]

Suppose you have a thread that is supposed to do this.

Transfer 2000 bucks from Person X's account to Person Y's account.

So the run method has, let's say, following logic.

1. Check if both the account numbers are valid.
2. Check if X has amount >2000 in his account.
3. Debit 2000 from X's account.
4. Credit 2000 into Y's account.

Now let us say somebody killed/stopped the thread after point 3. So now, the two objects here ( let us say X's account and Y's account ), are in inconsistent state.
2000 bucks that were debited from X's account are lost.

This is an example of damaged objects. Y's account is in a damaged state and so is X's account.
Hope that explains.

And why would a thread have another thread be able to control when it should stop execution, or to kill it in the middle of some processing?

Wouldn't it create a big blunder if other threads were able to reset the interrupted status bit of a thread via the isInterrupted method? And here we are talking about killing a thread!

[Rohit Kumar Singh]

Ulf Dittmer wrote:
Let's be precise: Stopping a thread doesn't put any object into an unusable state - using Thread.stop() does that. Stopping a thread as suggested above is fine. While it's good to be curious, in this particular case I would just accept that you should not use those methods and move on. The explanation is highly technical, and won't make sense unless you know the internals of the JVM very well (very few people do).

OK got it...

mean's i don't have to use these methods .

[Chan Ag]

Thanks, Steve. :-)

[Steve Luke]

Let's use your thread that reads packets from a socket. Let's say that the thread is in the middle of reading from the socket when the thread is stopped. What state is the socket left in? It had an open connection in the killed thread, but the thread stopped before it could release the connection. Also, what about the bytes being read from the socket? What happened to them? Are they available or not? Let's say you were gathering the bytes from the socket into an Object which you then were to pass to a different thread. How far along is the Object creation? What contents does it have? How does the receiving thread work with the partial data collected from the socket? Can it even work with the data? Let's also say you were synchronized on the data object to get good inter-thread synchronization and signaling for when the data was read and ready. Since the socket reading thread was stop()ed it doesn't release the lock. Now all the other threads counting on the signal and/or the lock are blocked forever.

There are many things that could be broken if you don't know that a task us being stopped and process it accordingly. The Thread.stop() method wouldn't give you the chance to process and clean up, so whatever you were doing will be in a bad state and every other thread will suffer from it. By deprecating it Java is forcing you to think about how to process a stop request so the issues appropriate to your task can be handled gracefully.

[Rohit Kumar Singh]

Steve Luke wrote:
There are many things that could be broken if you don't know that a task us being stopped and process it accordingly. The Thread.stop() method wouldn't give you the chance to process and clean up, so whatever you were doing will be in a bad state and every other thread will suffer from it. By deprecating it Java is forcing you to think about how to process a stop request so the issues appropriate to your task can be handled gracefully.

Got it Sir...



Will Work on it ..

[Rohit Kumar Singh]

Chan Ag wrote:Suppose you have a thread that is supposed to do this.

Transfer 2000 bucks from Person X's account to Person Y's account.

So the run method has, let's say, following logic.

1. Check if both the account numbers are valid.
2. Check if X has amount >2000 in his account.
3. Debit 2000 from X's account.
4. Credit 2000 into Y's account.

Now let us say somebody killed/stopped the thread after point 3. So now, the two objects here ( let us say X's account and Y's account ), are in inconsistent state.
2000 bucks that were debited from X's account are lost.

This is an example of damaged objects. Y's account is in a damaged state and so is X's account.
Hope that explains.

And why would a thread have another thread be able to control when it should stop execution, or to kill it in the middle of some processing?

Wouldn't it create a big blunder if other threads were able to reset the interrupted status bit of a thread via the isInterrupted method? And here we are talking about killing a thread!

Thanks sir for such a fine Example ..

[Chan Ag]

Rohit Kumar Singh wrote:

Thanks sir for such a fine Example ..

You're welcome. And Chan is just fine.

[Rohit Kumar Singh]

Chan Ag wrote:And Chan is just fine.