On 1/8/2014 1:26 AM, David Holmes wrote:
IMO, it seems that the ThreadInfo was not updated to reflect the
introduction of the park()/unpark() methods. In the current state it
mistakenly reports parking a thread as blocking but if the
implementation is updated to include only blocking on monitor entry (to
correspond to the API docs) we will miss the information about the
thread being parked (when the thread also does not execute any user
code). This would most probably call for the update of ThreadInfo API.
park() puts you in Thread.State WAITING which is exposed via
ThreadInfo.getWaitedCount, so I don't see any issue there. If parking
is causing a change to the blocked count then that is a major bug in
the underlying MXBean implementation.
David is right that LockSupport.park (and parkUntil or parkNanos)
transitions the thread state to WAITING (and TIMED_WAITING) [1]. Similar
to Object.wait, the current thread is waiting for another thread to
unpark it (i.e. make the permit available for it).
Mandy
[1]
http://download.java.net/jdk8/docs/api/java/lang/Thread.State.html#WAITING
