RFR 8030847: java/lang/management/ThreadMXBean/ThreadBlockedCount.java fails intermittently again

[Mandy Chung]

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