The Threads tab displays all threads that are part of the program being debugged. Depending on what thread view mode you are currently in, you may see all threads either in a single list (Flat View), arrange by thread groups (Group View), or arranged hierarchically where thread groups can contain other thread groups (Hierarchical View).
Anytime the debugger is paused, one of the threads in the list will be the current thread, which can be identified as the one with a yellow arrow pointing next to it. Only the stack frames of the current thread will be displayed in the Call Stack tab.
To switch to a different thread, simply double-click on the thread in this list. Double-clicking on a thread group will just expand or collapse the thread group.
Similarly, the threads table will be empty if the debuggee is running. Threads are visible only when debuggee is paused.
Name Column
This will show the name of the thread. The name of a thread will be the string that is returned from Thread.getName(). To assign a thread a name, you should pass the name to the Thread's constructor or set it with Thread.setName() in your program's code. If you do no provide a thread name, a default one will be supplied by the Thread class. These default names will have format "Thread-<integer>" and all automatically generated names will be unique although there is no requirement that it must be unique. You may find that supplying meaningful names to your threads will be helpful when debugging your multi-threaded programs.
Class Column
Displays the fully-qualified name of the actual class of the thread.
Status Column
Displays the thread's current status or status just before the debug session was paused. Possible status values are: unknown, not started, zombie, running, sleeping, monitor wait, and cond. wait.
Some debug VM's do not support displaying thread status so this column will always display unknown.
A thread whose status is condition wait (cond. wait) indicates it has called Object.wait() and is waiting to be notified when the condition is correct for the thread to continue executing. Before a thread can call wait() on the receiver object, the thread must be the monitor owner for that object. Typically wait() is called whenever it is determined by your code that the current program state does not permit the thread to continue executing because the thread may be waiting for some resource to become available or for some event to occur. A thread calling wait() will release its monitor lock on the object receiver of the wait() method call (thread will continue holding monitor locks on all other objects) and the thread will remain suspended until another thread calls notify() or notifyAll().
A thread whose status is monitor wait indicates that the thread is currently suspended, waiting to gain a monitor lock on a certain object. This happens for instance whenever a thread is trying to enter a synchronized block or method and another thread currently has a lock on the monitor object we are trying to gain access to.
A thread whose status is sleeping indicates that thread is currently suspended because Thread.sleep() or the deprecated Thread.suspend() method has been called. A thread that calls sleep() or suspend() retains all held object monitors it may be holding.
Executable Column
By default, all threads are executable. BugSeeker allows you to manually mark one or more threads as not-executable so that when you resume the debugging session, those threads marked not-executable will remain suspended. All threads are initially executable by default. To make a thread non-executable, uncheck the option for that thread in the Executable column.
You must be careful when you manually mark a thread as not executable as these threads will continue holding any object monitors it may have so a deadlock might occur if threads that are executable needs these monitors when execution is resumed.
Also, you probably should not modify the executable status for threads in the system thread group although most JVMs will ignore your request to make these threads not-executable.
ID Column
Displays a unique object identifier that has been assigned to the thread or thread group by the debuggee's VM. This value is useful as it will let you quickly determine if two objects are the same when they have the same identifier value. Object identifiers are unique and relevant only within the current debug session.
Hierarchical, Group and Flat thread views
Hierarchical thread view closely matches that way Java threads are actual organized within the VM.
Group thread view is more convenient if you are only interested in viewing threads within a single thread group and don't wish to see threads in other groups.
Flat view presents all threads as a single list without regard to thread group. This is the quickest way to get a quick view of all threads in your program.