CODEWITHSUNDEEP
javamultithreadingeclipsestack-trace
EoH
EoH

Reputation: 821

Detect Who Created a Thread (w. Eclipse)

How can I find out who created a Thread in Java?

Imagine the following: You use ~30 third party JARs in a complex plugin environment. You start it up, run lots of code, do some calculations and finally call shutdown().

This life-cycle usually works fine, except that on every run some (non-daemonic) threads remain dangling. This would be no problem if every shutdown was the last shutdown, I could simply run System.exit() in that case. However, this cycle may run several times and it's producing more garbage every pass.

So, what should I do? I see the threads in Eclipse's Debug View. I see their stack traces, but they don't contain any hint about their origin. No creator's stack trace, no distinguishable class name, nothing.

Does anyone have an idea how to address this problem?

Upvotes: 23

Views: 4474

Answers (5)

Kenston Choi
Kenston Choi

Reputation: 2942

For local debugging purposes, one can attach a debugger to a Java application as early as possible.

Set a non-suspending breakpoint at the end of java.lang.Thread#init(java.lang.ThreadGroup, java.lang.Runnable, java.lang.String, long, java.security.AccessControlContext, boolean) that will Evaluate and log the following:

"**" + getName() + "**\n" + Arrays.toString(Thread.currentThread().getStackTrace())

This will out the thread name and how the thread is created (stacktrace) that one can just scan through.

Upvotes: 1

Brian Agnew
Brian Agnew

Reputation: 272257

I religiously name my threads (using Thread(Runnable, String), say), otherwise they end up with a generic and somewhat useless name. Dumping the threads will highlight what's running and (thus) what's created them. This doesn't solve 3rd party thread creation, I appreciate.

EDIT: The JavaSpecialist newsletter addressed this issue recently (Feb 2015) by using a security manager. See here for more details

MORE: A couple of details for using the JavaSpecialist technique: The SecurityManager API includes "checkAccess(newThreadBeingCreated)" that is called on the thread creator's thread. The new thread already has its "name" initialized. So in that method, you have access to both the thread creator's thread, and the new one, and can log / print etc. When I tried this the code being monitored started throwing access protection exceptions; I fixed that by calling it under a AccessController.doPriviledged(new PrivilegedAction() { ... } where the run() method called the code being monitored.

Upvotes: 10

EoH
EoH

Reputation: 821

Okay, I was able to solve (sort of) the problem on my own: I put a breakpoint into 

Thread.start()

and manually stepped through each invocation. This way I found out pretty quickly that Class.forName() initialized lot of static code which in return created these mysterious threads.

While I was able to solve my problem I still think the more general task still remains unaddressed.

Upvotes: 15

Manuel Selva
Manuel Selva

Reputation: 19050

When debuging your Eclipse application, you can stop all thread by clicking org.eclipse.equinox.launcher.Main field in the debug view.

Then from there, for each thread you can see the stack trace and goes up to the thred run method.

Sometimes this can help and sometimes not.

As Brian said, it a good practice to name threads because it's the only way to easily identify "who created them"

Upvotes: 1

EoH
EoH

Reputation: 821

Unfortunately it doesn't. Within Eclipse I see all the blocking threads, but their stack traces only reflect their internal state and (apparently) disclose no information about the location of their creation. Also from a look inside the object (using the Variables view) I was unable to elicit any further hints.

Upvotes: 0

Related Questions