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_namejdb [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 HelloInitializing jdb ...> stop in Hello.mainDeferring breakpoint Hello.main.It will be set after the class is loaded.> runrun HelloSet uncaught java.lang.ThrowableSet deferred uncaught java.lang.Throwable>VM Started: Set deferred breakpoint Hello.mainBreakpoint hit: "thread=main", Hello.main(), line=3 bci=03          System.out.println("Hello world!");main[1] nextHello world!>Step completed: "thread=main", Hello.main(), line=4 bci=84       }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 HelloSet uncaught java.lang.ThrowableSet deferred uncaught java.lang.ThrowableInitializing jdb ...>VM Started: No frames on the current call stackmain[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                 TargetOption                    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 HelloListening 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 MyHelloSet uncaught java.lang.ThrowableSet deferred uncaught java.lang.ThrowableInitializing jdb ...>VM Started: No frames on the current call stackmain[1] stop in Hello.mainDeferring breakpoint Hello.main.It will be set after the class is loaded.main[1] cont> Set deferred breakpoint Hello.mainBreakpoint hit: "thread=main", Hello.main(), line=3 bci=03          System.out.println("Hello world!");main[1] list1    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 HelloListening 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=8888Set uncaught java.lang.ThrowableSet deferred uncaught java.lang.ThrowableInitializing jdb ...>VM Started: No frames on the current call stackmain[1] stop in Hello.mainDeferring breakpoint Hello.main.It will be set after the class is loaded.main[1] cont> Set deferred breakpoint Hello.mainBreakpoint hit: "thread=main", Hello.main(), line=3 bci=03          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:8888java.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 applicationthreads [threadgroup]     -- list threadsthread <thread id>        -- set default threadsuspend [thread id(s)]    -- suspend threads (default: all)resume [thread id(s)]     -- resume threads (default: all)where [<thread id> | all] -- dump a thread‘s stackup [n frames]             -- move up a thread‘s stackdown [n frames]           -- move down a thread‘s stackkill <thread id> <expr>   -- kill a thread with the given exceptioninterrupt <thread id>     -- interrupt a threadprint <expr>              -- print value of expressiondump <expr>               -- print all object informationeval <expr>               -- evaluate expression (same as print)set <lvalue> = <expr>     -- assign new value to a variablelocals                    -- print all local variablesclasses                   -- list currently known classesclass <class id>          -- show details of named classmethods <class id>        -- list a class‘s methodsfields <class id>         -- list a class‘s fieldsthreadgroups              -- list threadgroupsthreadgroup <name>        -- set current threadgroupstop in <class id>.<method>[(argument_type,...)]                          -- set a breakpoint in a methodstop at <class id>:<line> -- set a breakpoint at a lineclear <class id>.<method>[(argument_type,...)]                          -- clear a breakpoint in a methodclear <class id>:<line>   -- clear a breakpoint at a lineclear                     -- list breakpointscatch [uncaught|caught|all] <class id>|<class pattern>                          -- break when specified exception occursignore [uncaught|caught|all] <class id>|<class pattern>                          -- cancel ‘catch‘watch [access|all] <class id>.<field name>                          -- watch access/modifications to a fieldunwatch [access|all] <class id>.<field name>                          -- discontinue watchingtrace methods [thread]    -- trace method entry and exituntrace methods [thread]  -- stop tracing method entry and exitstep                      -- execute current linestep up                   -- execute until the current method returnsstepi                     -- execute current instructionnext                      -- step one line (step OVER calls)cont                      -- continue execution from breakpointlist [line number|method] -- print source codeuse (or sourcepath) [source file path]                          -- display or change the source pathclasspath                 -- print classpath info from target VMmonitor <command>         -- execute command each time the program stopsmonitor                   -- list monitorsunmonitor <monitor#>      -- delete a monitorread <filename>           -- read and execute a command filelock <expr>               -- print lock info for an objectthreadlocks [thread id]   -- print lock info for a threaddisablegc <expr>          -- prevent garbage collection of an objectenablegc <expr>           -- permit garbage collection of an object!!                        -- repeat last command<n> <command>             -- repeat command n timeshelp (or ?)               -- list commandsversion                   -- print version informationexit (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 PrimeNumberSeekerPeriod, Current int, # primes1, 2, 02, 12, 53, 22, 84, 32, 115, 42, 136, 52, 157, 62, 188, 72, 209, 82, 2210, 92, 2411, 102, 2612, 112, 2913, 122, 30...53, 521, 9854, 531, 9955, 541, 10056, 541, 10057, 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 PrimeNumberSeekerInitializing jdb ...> stop in PrimeNumberSeeker.mainDeferring breakpoint PrimeNumberSeeker.main.It will be set after the class is loaded.> runrun PrimeNumberSeekerSet uncaught java.lang.ThrowableSet deferred uncaught java.lang.Throwable>VM Started: Set deferred breakpoint PrimeNumberSeeker.mainBreakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=13 13          System.out.println("Period, Current int, # primes");

main[1] stop in PrimeNumberSeeker.runSet breakpoint PrimeNumberSeeker.runmain[1] contPeriod, Current int, # primes1, 2, 0>Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=2828          primes = new int[ceiling];Thread-0[1] threadsGroup system:  (java.lang.ref.Reference$ReferenceHandler)0xe2 Reference Handler  (java.lang.ref.Finalizer$FinalizerThread)0xe1  Finalizer          (java.lang.Thread)0xe0                         Signal DispatcherGroup 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 allSignal 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] next2, 2, 0>Step completed: "thread=Thread-0", PrimeNumberSeeker.run(), line=2929          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] next3, 2, 0>30             current++;Thread-0[1] next4, 3, 0>31             int j = 2;

Thread-0[1] next> 5, 3, 032             boolean isPrime = true;Thread-0[1] next6, 3, 0>33             while (j<current/2 && isPrime) {Thread-0[1] list29          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] next7, 3, 0>37             if (isPrime) {Thread-0[1] print isPrime isPrime = trueThread-0[1] next8, 3, 0>38                count++;Thread-0[1] next9, 3, 0>39                primes[count-1] = current;Thread-0[1] print count count = 1Thread-0[1] next> 10, 3, 142                sleep(delay);Thread-0[1] list38                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:19Set breakpoint PrimeNumberSeeker:19Thread-0[1] cont>Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=19 bci=2519             System.out.println( i+", "+t.current+", "+t.count);main[1] where allmain:  [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 = 11main[1] print t.current t.current = 3main[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=2519             System.out.println( i+", "+t.current+", "+t.count);main[1] print t.current t.current = 14main[1] print t.count t.count = 6main[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 280Thread-0[1] listCurrent method is nativeThread-0[1] step out11, 22, 8>Step completed: "thread=Thread-0", PrimeNumberSeeker.run(), line=4545             }Thread-0[1] list41             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:39Set breakpoint PrimeNumberSeeker:39Thread-0[1] cont>Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=3939                primes[count-1] = current;Thread-0[1] cont>Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=1919             System.out.println( i+", "+t.current+", "+t.count);main[1] cont> 12, 23, 9Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=3939                primes[count-1] = current;Thread-0[1] cont>Breakpoint hit: "thread=main", PrimeNumberSeeker.main(), line=1919             System.out.println( i+", "+t.current+", "+t.count);main[1] suspend 1main[1] cont>Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=3939                primes[count-1] = current;Thread-0[1] cont>Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=3939                primes[count-1] = current;Thread-0[1] cont>Breakpoint hit: "thread=Thread-0", PrimeNumberSeeker.run(), line=3939                primes[count-1] = current;Thread-0[1] print current current = 41Thread-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.ThrowableSet deferred uncaught java.lang.ThrowableInitializing jdb ...< threadsGroup 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. waitingGroup 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. waitingGroup 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 0x25cbbtpool0-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-0btpool0-0[1] instance of com.site.package.name(name=‘btpool0-0‘, id=9675) killedbtpool0-0[1]

Exit the java debugger, and you’re done!

-dan

jdb