http://herongyang.com/jtool/jdb.html
http://www.rhcedan.com/2010/06/22/killing-a-java-thread/
用处：上去杀死一个线程，！
"jdb" Command
"jdb": A command line tool that allows you to debug a Java application interactively with in a command line mode. "javac" is distributed as part of the Sun JDK package. It has the following syntax:
jdb [options] main_class_name jdb [options] -attach <address>
where "options" is a list of options, "main_class_name" is a the name of the main class of a Java application, and "address" is the debugging connection address of a running Java application.
As you can see from the syntax, there are two ways of running "jdb":
1. Running "jdb" to launch a Java application and start a debug session on that application.
2. Running "jdb" to connect to a separately launched Java application and start a debug session on that application.
Commonly used options are:
- "-help" - Displays a short help text.
- "-verbose" - Generates verbose output to standard output.
- "-classpath classpath" - Specifies a list of path names where the launcher will search for compiled type definitions.
- "-Dproperty=value" - Defines a new system property, which can be accessed by the application.
- "-launch" - Launches the debugged application immediately upon startup of jdb. This option removes the need for using the run command. The target application is launched and then stopped just before the initial application class is loaded. At that point you can set any necessary breakpoints and use the cont to continue execution.
Note that in order to use all debugging commands, the target application must be compiled with "-g" option, which will generate all debugging information, including source file, line number, and local variables, into the class file.
Launching and Debugging Java Applications
To test the debugger, I wrote the following simple Java application, Hello.java:
class Hello {
public static void main(String[] a) {
System.out.println("Hello world!");
}
}
Here is what I did in a command window to run "jdb" to launch and debug Hello.java:
>javac Hello.java
>jdb Hello
Initializing jdb ...
> stop in Hello.main
Deferring breakpoint Hello.main.
It will be set after the class is loaded.
> run
run Hello
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint Hello.main
Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0
3 System.out.println("Hello world!");
main[1] next
Hello world!
>
Step completed: "thread=main", Hello.main(), line=4 bci=8
4 }
main[1] cont
>
The application exited
Notice that:
- Once started, "jdb" offers you command prompt to allow you to run debugging commands interactively.
- Without the "-launch" option, "jdb" will not start the main() method of the specified class.
- "stop in" command sets a breakpoint at the beginning of the specified method. See the next section for other commonly used debugging commands.
- "run" command starts a new JVM process with run your application in debug mode.
- "jdb" and the JVM of your application are different processes. If you use Windows Task Manager, you should see two processes named as "jdb" and "java".
- "next" command executes only the current statement of the debugged application.
- "cont" command resumes the execution to the end or the next breakpoint.
If you want to launch the target application immediately, you can use the "-launch" option:
>jdb -launch Hello Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb ... > VM Started: No frames on the current call stack main[1] cont > Hello world! The application has been disconnected
As we expected, "jdb -launch" command launches the target application immediately, and stops at the beginning of the main() method.
Attaching "jdb" to Running Applications
If you ask "Can I launch the debugger (‘jdb‘) and the target application separately?", the answer is "Yes, you can.". In JDK 1.5, both "jdb" and "java" have been enhanced to use the latest JPDA (Java Platform Debugger Architecture) technology to give you the following options:
Debugger Target
Option jdb java
1 Shared memory client Shared memory server
2 Shared memory server Shared memory client
3 Socket client Socket server
4 Socket server Socket client
The shared memory options requires that the debugger and the target application to be on the same machine. Of course, the socket options allow you to run them remotely.
Let‘s try option #1 first. Open a command window on a windows system and run:
>java -agentlib:jdwp=transport=dt_shmem,address=MyHello,server=y, suspend=y Hello Listening for transport dt_shmem at address: MyHello
The target application is launched in "shared memory server" mode. Its execution is suspended. Now open another command window and run:
>jdb -attach MyHello
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
>
VM Started: No frames on the current call stack
main[1] stop in Hello.main
Deferring breakpoint Hello.main.
It will be set after the class is loaded.
main[1] cont
> Set deferred breakpoint Hello.main
Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0
3 System.out.println("Hello world!");
main[1] list
1 public class Hello {
2 public static void main(String[] a) {
3 => System.out.println("Hello world!");
4 }
5 }
main[1] cont
>
The application exited
As you can see, the debugger successfully connected to the target application. I used "next" command to let the target application to execute the current statement.
Let‘s try option #3 first. Open a command window on a windows system and run:
>java -agentlib:jdwp=transport=dt_socket,address=localhost:8888,server=y, suspend=y Hello Listening for transport dt_socket at address: 8888
The target application is launched in "socket server" mode. Its execution is suspended. Now open another command window and run:
>jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8888
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
>
VM Started: No frames on the current call stack
main[1] stop in Hello.main
Deferring breakpoint Hello.main.
It will be set after the class is loaded.
main[1] cont
> Set deferred breakpoint Hello.main
Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0
3 System.out.println("Hello world!");
main[1] quite
Cool. I know how to run "jdb" to debug an application running on a remote machine now!
However, the command suggested in the JPDA documentation did not work:
>jdb -attach localhost:8888
java.io.IOException: shmemBase_attach failed: The system cannot find
the file specified
at com.sun.tools.jdi.SharedMemoryTransportService.attach0(...
...
My guess is that the Windows version of "jdb" assumes "shared memory" as the default transport mode.
Debugging Commands
Ok, I think we did enough about launching the debugger and connecting to the target application. Let‘s now move on to look at some debugging commands.
Here is list of commonly used debugging commands. I got this list by using "help" at debugging prompt.
run [class [args]] -- start execution of an application
threads [threadgroup] -- list threads
thread <thread id> -- set default thread
suspend [thread id(s)] -- suspend threads (default: all)
resume [thread id(s)] -- resume threads (default: all)
where [<thread id> | all] -- dump a thread‘s stack
up [n frames] -- move up a thread‘s stack
down [n frames] -- move down a thread‘s stack
kill <thread id> <expr> -- kill a thread with the given exception
interrupt <thread id> -- interrupt a thread
print <expr> -- print value of expression
dump <expr> -- print all object information
eval <expr> -- evaluate expression (same as print)
set <lvalue> = <expr> -- assign new value to a variable
locals -- print all local variables
classes -- list currently known classes
class <class id> -- show details of named class
methods <class id> -- list a class‘s methods
fields <class id> -- list a class‘s fields
threadgroups -- list threadgroups
threadgroup <name> -- set current threadgroup
stop in <class id>.<method>[(argument_type,...)]
-- set a breakpoint in a method
stop at <class id>:<line> -- set a breakpoint at a line
clear <class id>.<method>[(argument_type,...)]
-- clear a breakpoint in a method
clear <class id>:<line> -- clear a breakpoint at a line
clear -- list breakpoints
catch [uncaught|caught|all] <class id>|<class pattern>
-- break when specified exception occurs
ignore [uncaught|caught|all] <class id>|<class pattern>
-- cancel ‘catch‘
watch [access|all] <class id>.<field name>
-- watch access/modifications to a field
unwatch [access|all] <class id>.<field name>
-- discontinue watching
trace methods [thread] -- trace method entry and exit
untrace methods [thread] -- stop tracing method entry and exit
step -- execute current line
step up -- execute until the current method returns
stepi -- execute current instruction
next -- step one line (step OVER calls)
cont -- continue execution from breakpoint
list [line number|method] -- print source code
use (or sourcepath) [source file path]
-- display or change the source path
classpath -- print classpath info from target VM
monitor <command> -- execute command each time the program stops
monitor -- list monitors
unmonitor <monitor#> -- delete a monitor
read <filename> -- read and execute a command file
lock <expr> -- print lock info for an object
threadlocks [thread id] -- print lock info for a thread
disablegc <expr> -- prevent garbage collection of an object
enablegc <expr> -- permit garbage collection of an object
!! -- repeat last command
<n> <command> -- repeat command n times
help (or ?) -- list commands
version -- print version information
exit (or quit) -- exit debugger
Multi-Thread Debugging Exercise
To help me practice debugging commands, I wrote the following simple application, PrimeNumberSeeker.java:
1 /**
2 * PrimeNumberSeeker.java
3 * Copyright (c) 2003 by Dr. Herong Yang, http://www.herongyang.com/
4 */
5 public class PrimeNumberSeeker extends Thread {
6 private static final int ceiling = 100;
7 private static final int interval = 1000;
8 private static final int delay = 100;
9 public int count = 0;
10 public int current = 2;
11 public int[] primes = null;
12 public static void main(String[] a) {
13 System.out.println("Period, Current int, # primes");
14 PrimeNumberSeeker t = new PrimeNumberSeeker();
15 t.start();
16 int i = 0;
17 while (true) {
18 i++;
19 System.out.println( i+", "+t.current+", "+t.count);
20 try {
21 sleep(interval);
22 } catch (InterruptedException e) {
23 System.out.println("Monitor interrupted.");
24 }
25 }
26 }
27 public void run() {
28 primes = new int[ceiling];
29 while (count < ceiling) {
30 current++;
31 int j = 2;
32 boolean isPrime = true;
33 while (j<current/2 && isPrime) {
34 isPrime = current % j > 0;
35 j++;
36 }
37 if (isPrime) {
38 count++;
39 primes[count-1] = current;
40 }
41 try {
42 sleep(delay);
43 } catch (InterruptedException e) {
44 System.out.println("Runner interrupted.");
45 }
46 }
47 }
48 }
Note that:
- This application tries to use a sub-thread to calculate prime numbers.
- The main thread is monitoring how the sub-thread is doing.
- A delay mechanism is used to slow the calculation.
- The application has an infinite loop. So you have to terminate it by "Ctrl-C".
Here is how I compiled the application and executed without debugging:
>javac -g PrimeNumberSeeker.java >java PrimeNumberSeeker Period, Current int, # primes 1, 2, 0 2, 12, 5 3, 22, 8 4, 32, 11 5, 42, 13 6, 52, 15 7, 62, 18 8, 72, 20 9, 82, 22 10, 92, 24 11, 102, 26 12, 112, 29 13, 122, 30 ... 53, 521, 98 54, 531, 99 55, 541, 100 56, 541, 100 57, 541, 100 ...
The output seems to be fine. But I want to use "jdb" to exam the calculation and to practice the debugging commands. Below I will show my debugging session in multiple parts with my comments.
1. Setting up breakpoints and getting the debugging session going:
>jdb PrimeNumberSeeker
Initializing jdb ...
> stop in PrimeNumberSeeker.main
Deferring breakpoint PrimeNumberSeeker.main.
It will be set after the class is loaded.
> run
run PrimeNumberSeeker
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint PrimeNumberSeeker.main
Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=13
13 System.out.println("Period, Current int, # primes");
main[1] stop in PrimeNumberSeeker.run Set breakpoint PrimeNumberSeeker.run main[1] cont Period, Current int, # primes 1, 2, 0 > Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=28 28 primes = new int[ceiling]; Thread-0[1] threads Group system: (java.lang.ref.Reference$ReferenceHandler)0xe2 Reference Handler (java.lang.ref.Finalizer$FinalizerThread)0xe1 Finalizer (java.lang.Thread)0xe0 Signal Dispatcher Group main: (java.lang.Thread)0x1 main running (PrimeNumberSeeker)0x118 Thread-0 running (at breakpoint)
Ok. What I have done so far:
- Started the debugging session with the first breakpoint at the beginning of the main() method, which cause the execution to stop at line 13.
- Then I created the second breakpoint at the beginning of the run() method in order to catch the sub thread.
- Then I issued the "cont" command. My application continued with the sub thread created stopped at the breakpoint at line 28. The main thread also stopped.
- Noticed that the debugger prompt is changed from "main[1]" to "Thread-0[1]". This is to inform you that you are currently in the sub thread, no longer in the main thread.
- The I used the "threads" command to list all threads. I saw two thread groups: "system" and "main". Of course, I am not interested in the "system" group at this point. The "main" shows two threads: "main" (my monitoring thread) and "Thread-0" (my sub thread working on the calculation).
- Thread "Thread-0" status shows "running (at breakpoint)". But the word "running" is referring to the thread execution mode, not the current execution status.
- Notice that tread "main" is also stopped at this moment. As a general rule, if one thread is stopped, all other threads are stopped also.
2. Stepping through the sub thread:
Thread-0[1] where all
Signal Dispatcher:
Finalizer:
[1] java.lang.Object.wait (native method)
[2] java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:111)
[3] java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:127)
[4] java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:...
Reference Handler:
[1] java.lang.Object.wait (native method)
[2] java.lang.Object.wait (Object.java:429)
[3] java.lang.ref.Reference$ReferenceHandler.run (Reference.java...
main:
[1] java.lang.Thread.sleep (native method)
[2] PrimeNumberSeeker.main (PrimeNumberSeeker.java:21)
Thread-0:
[1] PrimeNumberSeeker.run (PrimeNumberSeeker.java:28)
Thread-0[1] next
2, 2, 0
>
Step completed: "thread=Thread-0", PrimeNumberSeeker.run(), line=29
29 while (count < ceiling) {
Thread-0[1] where all
...
main:
[1] java.lang.Thread.sleep (native method)
[2] PrimeNumberSeeker.main (PrimeNumberSeeker.java:21)
Thread-0:
[1] PrimeNumberSeeker.run (PrimeNumberSeeker.java:29)
Thread-0[1] next
3, 2, 0
>
30 current++;
Thread-0[1] next
4, 3, 0
>
31 int j = 2;
Thread-0[1] next
> 5, 3, 0
32 boolean isPrime = true;
Thread-0[1] next
6, 3, 0
>
33 while (j<current/2 && isPrime) {
Thread-0[1] list
29 while (count < ceiling) {
30 current++;
31 int j = 2;
32 boolean isPrime = true;
33 => while (j<current/2 && isPrime) {
34 isPrime = current % j > 0;
35 j++;
36 }
37 if (isPrime) {
38 count++;
Thread-0[1] print current
current = 3
What I have done here:
- I used "where all" to display the current location of all threads.
- Then I used "next" to execute one statement in the current thread, the sub thread, going from line 28 to line 29.
- The next "where all" command showed me that the main thread went through an entire iteration of the "while" loop. The main thread stopped again at line 21.
- Then I used a couple of "next" command in the sub thread to bring the execution to line 33. At the same time, the main thread went through a couple of iterations, printed some output messages.
- Then I used "print" to check the current value of variable "current". Value 3 is correct.
3. Checking local variables:
Thread-0[1] next
7, 3, 0
>
37 if (isPrime) {
Thread-0[1] print isPrime
isPrime = true
Thread-0[1] next
8, 3, 0
>
38 count++;
Thread-0[1] next
9, 3, 0
>
39 primes[count-1] = current;
Thread-0[1] print count
count = 1
Thread-0[1] next
> 10, 3, 1
42 sleep(delay);
Thread-0[1] list
38 count++;
39 primes[count-1] = current;
40 }
41 try {
42 => sleep(delay);
43 } catch (InterruptedException e) {
44 System.out.println("Runner interrupted.");
45 }
46 }
47 }
Thread-0[1] print primes[0]
primes[0] = 3
What I have done here:
- I used "next" again. The sub thread jumped over the calculation loop between line 33 and 36. This is correct, since "current" has "3", a prime number, no need to do any calculation.
- Then I used "next" and "print" several times. I saw prime number 3 was correctly recorded in the "primes" array.
4. Going back to the main thread:
Thread-0[1] stop at PrimeNumberSeeker:19 Set breakpoint PrimeNumberSeeker:19 Thread-0[1] cont > Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=19 bci=25 19 System.out.println( i+", "+t.current+", "+t.count); main[1] where all main: [1] PrimeNumberSeeker.main (PrimeNumberSeeker.java:19) Thread-0: [1] java.lang.Thread.sleep (native method) [2] PrimeNumberSeeker.run (PrimeNumberSeeker.java:42) main[1] print i i = 11 main[1] print t.current t.current = 3 main[1] print t.count t.count = 1
What I have done here:
- I created another breakpoint in the main thread at line 19.
- Then I allowed both threads to run naturally to the next breakpoint, line 19. The command prompt is changed back to "main[1]".
- Then I used "where all" to check where the execution are stopped in all threads. It is interesting to see that the sub thread stopped inside the sleep() method.
- Then I checked some local variables, "i", "t.current", and "t.count". Their values were all correct.
5. Switching threads:
main[1] cont
>
Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=19 bci=25
19 System.out.println( i+", "+t.current+", "+t.count);
main[1] print t.current
t.current = 14
main[1] print t.count
t.count = 6
main[1] where all
...
main:
[1] PrimeNumberSeeker.main (PrimeNumberSeeker.java:19)
Thread-0:
[1] java.lang.Thread.sleep (native method)
[2] PrimeNumberSeeker.run (PrimeNumberSeeker.java:42)
main[1] threads
...
Group main:
(java.lang.Thread)0x1 main running
(PrimeNumberSeeker)0x118 Thread-0 running (at breakpoint)
main[1] thread 280
Thread-0[1] list
Current method is native
Thread-0[1] step out
11, 22, 8
>
Step completed: "thread=Thread-0", PrimeNumberSeeker.run(), line=45
45 }
Thread-0[1] list
41 try {
42 sleep(delay);
43 } catch (InterruptedException e) {
44 System.out.println("Runner interrupted.");
45 => }
46 }
47 }
48 }
Thread-0[1] print count
count = 8
What I have done here:
- I let the main thread executed a full period stopping at line 19 again. Of course, the sub thread execute some number of statements and stopped inside the sleep() native method.
- Then I listed all threads and want to find a way to switch the command prompt to the sub thread to check local variable there. The manual says to use "thread n", where n is the thread index to change the current thread. But where can I to get the thread index? I tried to search the Web and did not get any clear answer.
- However I got the answer from the output of the threads output. The thread index was listed as a hex number next to the class name. For example, "(PrimeNumberSeeker)0x118" means thread 0x118 = 280.
- So I used "thread 280" to switch to the sub thread as the current thread. Notice that the command prompt changed.
- The first "list" command did not work, because the sub thread was stopped inside the "sleep()" method. The "step out" command continued the execution just enough to finish "sleep()" and back to the caller, run().
6. Running one thread only:
Thread-0[1] stop at PrimeNumberSeeker:39 Set breakpoint PrimeNumberSeeker:39 Thread-0[1] cont > Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=39 39 primes[count-1] = current; Thread-0[1] cont > Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=19 19 System.out.println( i+", "+t.current+", "+t.count); main[1] cont > 12, 23, 9 Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=39 39 primes[count-1] = current; Thread-0[1] cont > Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=19 19 System.out.println( i+", "+t.current+", "+t.count); main[1] suspend 1 main[1] cont > Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=39 39 primes[count-1] = current; Thread-0[1] cont > Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=39 39 primes[count-1] = current; Thread-0[1] cont > Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=39 39 primes[count-1] = current; Thread-0[1] print current current = 41 Thread-0[1] print count count = 13
What I have done here:
- After check different areas of the code, I wanted to only the break the execution when a new prime number is found. So I created a breakpoint at line 39.
- Then I used "cont" to let the execution to continue. But two threads always executed at the same time, and stopped at the same time whenever one thread reached a breakpoint.
- So I used "suspend 1" to suspend the main thread. This is a cool command, allowing me to concentrate on a single thread. Of course, you can use "resume 1" to release the suspension.
I think I have done enough debugging practice and want to stop here now. However, my program does have a calculation error. I want to leave it to you to find out.
Conclusions
- "jdb" is a nice debugging tool. But it only offers a command line interface, not so easy to use. It is much more efficient to use graphical interface debugger.
- JPDA is well designed, allowing us to debug Java applications remotely.
- Debugging multi-thread application is tricky. The following "jdb" notes may help you.
- Whenever one thread reaches a break point, all other threads are stopped also.
- The command prompt tells what is the current thread.
- "where all" tells where the execution are currently in all threads.
- "threads" lists all the threads with thread indexes as Hex numbers.
This was amazingly impossible to find the answer to when I was looking for it.
The setup — running JVM, some thread doing something stupid like taking 100% CPU usage. For the purposes of my example, I will explain that I was using Jetty to serve a homegrown web application. With an Apache front-end, requests were being passed to Jetty over the AJP13 protocol using mod_jk.
Basically, the result of months of research turned out to be that a misconfigured client browser was passing a “Content-Length” value in the header of the request that was greater than the amount of data that was actually being supplied by the request. That’s stupid, right? What’s stupider is that in this situation, mod_jk winds up passing this crap along to Jetty, and with AJP13, Jetty sits there waiting for more data to come from the connector. But, there is no more data. So, away it would spin… until the service could be completely restarted, causing a service interruption for end-users. This was not acceptable, so before I was able to find what was actually causing the problem, I spent a long time finding a suitable work-around to the bug. The logical answer seemed to be “killing a java thread” — and I honestly thought that somebody else out there in the world had somehow found a way to kill a java thread. Apparently nobody in the mass of all google search results has ever found a way to kill a java thread that is attached to a running JVM, without destroying the entire JVM… at least not that I found.
So, for all of you guys out there that want/need to do the same thing — here’s your solution:
1) 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=n
This 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.
2) Identify the offending thread:
In order to identify the offending thread, I used the Java VisualVM
utility that is shipped with the JDK distribution. You can also use
JConsole, but VisualVM allows you to add in JConsole plugins, and the
look/feel is so much better than JConsole, so I use VisualVM. We’ll need
the JTop JConsole plugin, which you can find in /demo/management/JTop.jar. I trust you’ll be able to figure out how to get the plugin working…
The thread that is eating your CPU will be at the top of the list. For
the purposes of this example, the image below is an infant thread, so
the CPU(sec) column reflects only a few seconds worth of actual usage —
yours may/probably will be much higher.
3) 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:
Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb ... < threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x25c1 Reference Handler cond. waiting (java.lang.ref.Finalizer$FinalizerThread)0x25c2 Finalizer cond. waiting (java.lang.Thread)0x25c3 Signal Dispatcher running (java.lang.Thread)0x25c4 RMI TCP Accept-0 running (java.lang.Thread)0x25c5 RMI TCP Accept-50199 running (java.lang.Thread)0x25c6 RMI TCP Accept-0 running (java.lang.Thread)0x25c7 RMI Scheduler(0) cond. waiting Group main: (java.util.TimerThread)0x25ca Timer-0 cond. waiting (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25cb btpool0-0 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25cc btpool0-1 - Acceptor0 SelectChannelConnector@0.0.0.0:8080 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25cd btpool0-2 - Acceptor1 SelectChannelConnector@0.0.0.0:8080 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25ce btpool0-3 - Acceptor0 Ajp13SocketConnector@0.0.0.0:8009 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25cf btpool0-4 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25d0 btpool0-5 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25d1 btpool0-6 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25d2 btpool0-7 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25d3 btpool0-8 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25d4 btpool0-9 running (java.util.TimerThread)0x25d5 Timer-1 cond. waiting (java.lang.Thread)0x25d6 PoolScavenger0 cond. waiting (oracle.jdbc.pool.OracleImplicitConnectionCacheThread)0x25d8 Thread-15 sleeping (java.util.TimerThread)0x25d9 Timer-2 cond. waiting (java.lang.Thread)0x25db Thread-18 cond. waiting (java.util.TimerThread)0x25dc Timer-3 cond. waiting (java.util.TimerThread)0x25dd Timer-4 cond. waiting (java.lang.Thread)0x25de Northgate Server running (java.util.TimerThread)0x25df Timer-5 cond. waiting (java.util.TimerThread)0x25e0 Timer-6 cond. waiting (java.util.TimerThread)0x25e1 Timer-7 cond. waiting (java.util.TimerThread)0x25e2 Timer-8 cond. waiting (java.util.TimerThread)0x25e3 Timer-9 cond. waiting (java.lang.Thread)0x25e4 pool-1-thread-1 cond. waiting (java.util.TimerThread)0x25e5 Timer-10 cond. waiting (java.lang.Thread)0x25e6 DestroyJavaVM running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25e7 btpool0-10 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25e8 btpool0-11 running (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25e9 btpool0-12 running (oracle.jdbc.pool.OracleImplicitConnectionCacheThread)0x25ea Thread-756 sleeping (org.mortbay.thread.BoundedThreadPool$PoolThread)0x25eb btpool0-13 cond. waiting Group RMI Runtime: (java.lang.Thread)0x25ed JMX server connection timeout 51 cond. waiting (java.lang.Thread)0x25ee RMI TCP Connection(2687)-127.0.0.1 running >
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
Now, here’s the real trick, and the primary component of killing the thread that I was unable to find in all of the search that I had done… Step to the next frame.
btpool0-0[1] step > Step completed: <... snip ...>
This puts you in a position to inject a general exception into the running code (should probably be something that is uncaught), thereby exiting the running thread, and cleaning up objects gracefully within the JVM.
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!
-dan