I am working on a state sampling monitor. Its basic functions are:
a. wake up periodically
b. get thread state for threads of interest (e.g., some application's threads)
c. if the thread is blocked (BLOCKED, WAITING,..) then look more closely to get the monitor lock it's waiting on
d. record all this info in some kind of dictionary | array
The state sampling monitor runs concurrently with the application it's monitoring. When all is said and done, the recorded data should have entries like this (expressed in English): "thread 1 was found to be blocked 1000 times waiting on monitor lock A; thread 1 was found to be runnable 500 times; thread 1 was found to be blocked 9999 times waiting on monitor lock B," and so on.
It occurred to me that JVMTI might be a good way of accomplishing this. Specifically, I thought I might be able to use its event callbacks:
1. Will these event callbacks cover ALL types of thread waits?
2. Is there any way to determine that a thread is blocked because it’s waiting on I/O?
3. If the answer to (2) is “yes,” then is there any way to learn something about the I/O in question, e.g., what file | device it’s waiting on?
I had first thought to accomplish this via ThreadMXBean's getThreadInfo method. But I was concerned, perhaps needlessly, about the consistency of the information it returns. Specifically, does ThreadMXBean’s method
return a consistent representation of a thread? That is, suppose the following sequence:
a. When getThreadInfo is called, a target thread is BLOCKED, waiting on a monitor lock
b. The getThreadInfo call returns AND the formerly blocked target thread happens to start running
c. ThreadInfo.getThreadState is called on the ThreadInfo object that represents the target thread
d. ThreadInfo.getLockName is called on the ThreadInfo object that represents the target thread
Will (c) return BLOCKED? (remember, the target thread is now running)
Will (d) return the lock name that the target thread was waiting on at time (a)?