I m using windows 7 OS. I have around 6
threads in my application. For the purpose of testing the alerts to check the health of the threads, i need to kill the threads manually and check if the alerts are working properly. Can we kill a thread like how we kill a process with its pid
?

- 2,562
- 6
- 25
- 43
-
2The threads are an internal implementation detail of the application They are not visible or accessible from outside the application. If a thread dies unexpectedly, the application is unusable, since there is no isolation between threads. (Think about what happens if the thread holds a lock. If you release it, boom. If you don't release it, boom.) – David Schwartz Jul 23 '12 at 10:48
8 Answers
Dan Woods documented how to kill a thread in this blog entry... https://web.archive.org/web/20160302023213/http://www.rhcedan.com/2010/06/22/killing-a-java-thread The steps he performed involved using a debugger (JDB) and injecting an exception in the thread's execution. Specifically...
Ensure that your java program is started with the following parameters:
-Dcom.sun.management.jmxremote.port=50199
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Xrunjdwp:transport=dt_socket,address=50100,server=y,suspend=nThis will allow us to attach the java debugger to the running process, after we identify which Thread is causing the problem. Also, make sure that you have your iptables setup appropriately so as to only allow connections on 50100 and 50199 from the hosts/workstations that you manage.
- Identify the offending thread:
Kill the thread. In this example, the ThreadName is “btpool0-0?. Fire up the java debugger (also shipped with the JDK distribution), and attach to the running JVM…
[root@host ~]# jdb -attach 50100
Get a list of the running threads — this will also give us the thread id as the JVM sees it:
> threads
--snip--
(org.mortbay.thread.BoundedThreadPool$PoolThread)0x25cb
btpool0-0 running
--snip--
The thread id that we’re going to kill is “0x25cb”. The first step of killing the thread is to jump into it, and suspend it…
thread 0x25cb
btpool0-0[1] suspend 0x25cb
btpool0-0[1] step
Step completed: <... snip ...>
btpool0-0[1] kill 0x25cb new java.lang.Exception()
killing thread: btpool0-0
btpool0-0[1] instance of
com.site.package.name(name='btpool0-0', id=9675) killed btpool0-0[1]
Exit the java debugger, and you’re done!

- 1,683
- 2
- 20
- 38
-
Hi! Can you use jdb to connect to a remote host where the application exposes jmx ? – Sorin Postelnicu Oct 31 '18 at 17:45
There is no safe way to "kill" a thread without killing the process it is in. It not something you would do deliberately. For testing purposes I would add code to your application to support this.

- 525,659
- 79
- 751
- 1,130
-
But using Thread.stop is deprecated. I found this to be useful. http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html – Arun Jul 23 '12 at 10:49
-
1Which is why I said `There is no safe way to "kill" a thread` This doesn't stop you from using it for testing purposes. – Peter Lawrey Jul 23 '12 at 11:04
-
-
@Antoniossss in that case, decompile the critical sections of the code, add checks for Thread.currentThread().isInterrupted(), compile and use that code. If you are not sure where the critical sections are, use a profiler and/or take stack traces when the thread is busy running this code. – Peter Lawrey Jan 03 '19 at 11:34
It's not true. You can always attach to the JVM process with GDB and do a call pthread_kill if you know the thread id. You only need to translate from the java thread dump (do a kill -3) which gives you a hex id, (native id), then look into the list of threads in GDB (info threads) and locate the real thread id.
This is proven to work.

- 8,023
- 10
- 33
- 39

- 101
- 1
- 2
As Peter says, you can't do this safely. Indeed on some platforms Thread.kill
is not even implemented. However:
If this is just for testing, a unit test that called
Thread.kill
would be reasonable ... assuming it worked on the test platforms where it needed to work. (A "loud" comment in the source code would be in order to help people porting the unit test ...)Another alternative is to add some code to the thread runnable that allows your unit tests to tell it to die. If the thread code needs to be (almost) production code for this to work, you could create a subclass that overrides something so that it "breaks" in a way that suits your purposes ... for testing. In fact, this approach allows you to cause the threads "break" in controlled ways, potentially allowing you to test different aspects of your alerting code.

- 698,415
- 94
- 811
- 1,216
In java you can not kill the like unix . Either you can interrupt
the tread in java or you can kill the process in unix .

- 7,831
- 3
- 35
- 54
Wait for some time in the thread and kill the thread in the code - simple way.

- 1,850
- 1
- 19
- 42
-
I don't think you understand the question, and anyway as Peter Lawrey says, there is no safe way to kill a Java thread. – Stephen C Jul 23 '12 at 11:23
-
-
You can't make an uncooperative thread throw an exception. This is not about telling a thread to "kill itself". It is about killing a thread that is not listening ... and doing it in a way that *simulates* the an application failure in production. – Stephen C Jul 24 '12 at 01:14
As mentioned in a previous post by buzz3791, it works by using jdb. However the change that I noticed is, you can't kill the thread, but you can interrupt or suspend the thread.
#jdb -attach 50100
threads --This will show all threads running on the jvm under Groups and Reference Handler section.
Groups | Reference Handler |
---|---|
:(com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary)0x36c1: | OrientDB (/xxx.xxx.xxx.xxx:123) <- BinaryClient (/xxx.xxx.xxx.xxx:678) |
thread 0x36c1-- This will be the thread id that can be picked from one of the threads in the thread that you wish to kill/interrupt and run this interrupt 0x36c1
OrientDB (/xxx.xxx.xxx.xxx:123) <- BinaryClient (/xxx.xxx.xxx.xxx:678)[1] interrupt 0x36c1
you can try multiple times the same interrupt command and if it is already interrupted, it will show that the thread id is invalid. Thus you know that the thread is killed, this can be verified by looking at the stack trace and confirmed.
Tested this on the OrientDB database server with jdk 8 and it works.

- 23
- 1
- 6