Are there any liveness issues about thread scheduling in the JVM?
rednaxelafx at gmail.com
Sun Jul 15 19:20:22 PDT 2012
This is actually the source of my earlier mail "Multiple Java threads seem
to have locked the same object monitor from the thread dumps" .
Apparently Xiaodong didn't subscribe to the mailing list before sending his
mail to hotspot-dev, and while waiting for moderator approval he sent
another mail directly to me...
On Mon, Jul 16, 2012 at 8:55 AM, David Holmes <david.holmes at oracle.com>wrote:
> On 10/07/2012 9:20 PM, Xie Xiaodong wrote:
>> We are facing some interesting behavior in production.
>> Here are some thread dumps taken at different time. During this period,
>> only httpSSLWorkerThread-10080-99 can make progress. Other threads were
>> always stuck in the synchronization point. And "waiting to lock
>> <0x75b395d8>", this hex number changed several times. What does this
> An example:
> - waiting to lock <0x75b395d8> (a casinomodule.util.**TimeUtilImpl)
> The number is the address of an object that the threads are trying to
> lock. It is an instance of casinomodule.util.**TimeUtilImpl. If the
> address, for a given thread, keeps changing, it means that the threads are
> in fact making progress, as they must have locked object form the previous
> stack dump and then moved on to the current one. If the number is different
> for different threads then they are simply trying to lock different objects.
> There would appears to be a synchronization bottleneck in this
>> Thanks a lot for your time.
More information about the hotspot-dev