Java Thread Analysis

[Carl]

Does anyone know of a tool that can be used to track a thread's
lineage. We currently have the situation where several thousand
threads will be running in our system. We believe that some piece of
our code is causing too many threads to spawn. We have been able to
dump all of the threads and their names but sometimes it isn't useful
due to poor names and/or the threads being third party (such as a
CORBA thread.) We would like a tool that can tell us which class
started how many of each type of thread so that we may determine what
we can do (if anything) to prevent a "thread leak."

Thank you

 

[Steve W. Jackson]

oes anyone know of a tool that can be used to track a thread's
:lineage. We currently have the situation where several thousand
:threads will be running in our system. We believe that some piece of
ur code is causing too many threads to spawn. We have been able to
:dump all of the threads and their names but sometimes it isn't useful
:due to poor names and/or the threads being third party (such as a
:CORBA thread.) We would like a tool that can tell us which class
:started how many of each type of thread so that we may determine what
:we can do (if anything) to prevent a "thread leak."
:
:Thank you

I'm not sure how many profiling tools provide this, but Borland's
OptimizeIt that we use is one that does. While running our application,
it will show us all objects in existence, whether Threads or otherwise,
and will also show their origins -- that is, where they were allocated
onto the heap. If the source code is available, as it is in our use, it
can show the surrounding code where the allocation occurs.

= Steve =

 

[John C. Bollinger]

Does anyone know of a tool that can be used to track a thread's
lineage. We currently have the situation where several thousand
threads will be running in our system.
Wow.

We believe that some piece of
our code is causing too many threads to spawn.

That sounds like a safe bet. You have about two orders of magnitude too
many live threads for any one program.

We have been able to
dump all of the threads and their names but sometimes it isn't useful
due to poor names and/or the threads being third party (such as a
CORBA thread.) We would like a tool that can tell us which class
started how many of each type of thread so that we may determine what
we can do (if anything) to prevent a "thread leak."

If you're hoping to get such an analysis without modifying your code
then you're out of luck. Standard Thread objects are in no way bound to
the object or class that created them, any more than any generic object
is. If you do not capture or encode that information into the Thread
then you cannot later cajole it out of the system. So, since you have
to modify the code anyway, the easiest thing to do might be to find
every place in your code where you instantiate a Thread, and at each
place make sure to assign the new Thread a meaningful name (i.e. one
that will support the analysis you wish to perform).


John Bollinger
(e-mail address removed)

 

[William Brogden]

Does anyone know of a tool that can be used to track a thread's
lineage. We currently have the situation where several thousand
threads will be running in our system. We believe that some piece of
our code is causing too many threads to spawn. We have been able to
dump all of the threads and their names but sometimes it isn't useful
due to poor names and/or the threads being third party (such as a
CORBA thread.) We would like a tool that can tell us which class
started how many of each type of thread so that we may determine what
we can do (if anything) to prevent a "thread leak."

Thank you

Why not use ThreadGroups to provide a level of organization?

Bill

 

[Chris Smith]

Why not use ThreadGroups to provide a level of organization?

This doesn't really solve much. The OP's problem was that threads were
being created by third parties. If the OP had access to every thread as
it was created, then obviously each one could be given a descriptive
name, and the problem could be solved.

Aside from that, in general thread groups are considered poor form in
new code. They are an experiment that failed, and even Sun
documentation recommends against using them any longer.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Vladimir Kondratyev]

I think that YourKit Java Profiler (http://www.yourkit.com) can be
useful in your situation. You need to capture memory snapshot and open
all instances of java.lang.Thread.

 

[Carl]

Vladimir, thank you for the recommendation. I have downloaded the
evaluation version of your profiler and I have taken a few snapshots.
I opened all instances of java.lang.Runnable (Thread did not appear to
capture the Runnable interfaces.)

The profiler is useful in that it seems to answer the questions:
How many threads of each class are running?
Given a top level thread, what other threads were called by whom?

It does not appear to answer:
How many ThreadB's did ThreadA invoke?
Given a low level thread, what threads invoked it?

While the information retrieved is useful I believe that I need to get
the other information before I can solve my problem. Any advice is
appreciated?

 

[Stephen Kellett]

Does anyone know of a tool that can be used to track a thread's
lineage. We currently have the situation where several thousand
threads will be running in our system. We believe that some piece of

Java Thread Validator. Also detects deadlocks, etc.

http://www.softwareverify.com/publicBeta.html

Stephen

 

[John C. Bollinger]

The profiler is useful in that it seems to answer the questions:
How many threads of each class are running?
Given a top level thread, what other threads were called by whom?

It does not appear to answer:
How many ThreadB's did ThreadA invoke?

Do you mean "instantiate"? "Start"? Something else? Neither Threads
nor threads are "invoked". Moreover, Neither Threads nor threads
instantiate or start Threads, at least not in the sense that we usually
apply to the various actors in an object-oriented program. "Threads"
are object handles on "threads" of sequential execution. Various
objects may instantiate Thread objects, in the context of one or another
thread, and may, in the context of some possibly different thread, use
that Thread object to start a new thread. Once started, a thread does
not retain any sense of the thread that provided the context in which it
was started (neither directly nor via the corresponding Thread objects).
Likewise, a Thread object does not, any more than any other object,
retain any sense of the object that instantiated it, nor of the
object(s) that invoked any particular method on it (e.g. start()).

Given a low level thread, what threads invoked it?

That doesn't make any sense at all. Running threads do not invoke other
threads. They may synchronize with each other in a variety of ways.
They may access shared objects (but shared objects, by definition, do
not belong to any particular thread). If you have thread pool then you
could ask the question of which threads or objects have provided jobs
for particular threads in the pool, but unless you have coded some
logging mechanism to record that data at the time it occurs then there
is no reliable way to divine it later.

Details of the execution history of your program are not available from
the program state itself in the general case. As such, no debugger or
profiler is going to be able to give you some of the information you
seek unless you instrument the program to provide it (in which case a
debugger or profiler would be a rather clunky way to get at it, as
opposed, say, to a log file, thread names in a thread dump, etc.).


John Bollinger
(e-mail address removed)