[concurrency-interest] Advice on tracking down the caller of Thread.interrupt()?

Rémi Forax forax at univ-mlv.fr
Wed Mar 21 16:00:54 EDT 2012

On 03/21/2012 08:25 PM, Bryan Thompson wrote:
> Hello,
> I am curious if there are any tricks for tracking down the source of an interrupt. That is, the Thread which actually invoked Thread.interrupt() on some thread.
> We use a disk IO in a database with concurrent readers on a shared file. IO, of course, can be interrupted.  And when it is interrupted the backing channel is closed, so we have to jump through hoops to ensure that the channel is reopened for those threads which see the AsynchronousCloseException (or ClosedChannelException), while ensuring that the thread which sees the ClosedByInterruptException terminates its activity.
> Normally I can spot the source of an interrupt by looking at the context in which the interrupt occurs and work backward through the logic of the application to figure out why the Thread might have been interrupted.  However, this is difficult when our code is embedded into other applications when we have little to know idea what else might be going on.  In particular, I am looking at an issue now where I think that the interrupt might be coming from some other component.  For example, by holding onto a Thread reference beyond the life of a worker task and then interrupting that thread.
> Is it possible to somehow instrument the JVM to track and report the caller of Thread.interrupt()?  Are there profilers which can do this?  Can this be done somehow by registering a SecurityManager to log stack fames in Thread.checkAccess()?
> Thanks in advance,
> Bryan

You can do it by yourself, it's not hard :)

 From the directory that contains all JDK files, find the src.zip, which 
is roughly
a zip of the source of the public classes of the JDK.
Extract java/lang/Thread.java
Now, as you can see Thread::interrupt() is written in Java, so
you can add all the instructions you want :)
To get the caller class, use sun.reflect.reflection.getCallerClass(2) 
(see [1]),
because you are in a trusted class, you can call it.
Compile your class and prepend it in front of the bootclasspath,
so your classwill be loaded instead of the one from rt.jar
(see java -X and java -Xbootclasspath/p )



More information about the Concurrency-interest mailing list