[concurrency-interest] Measuring lock contention with ThreadMXBean

Joseph Seigh jseigh_cp00 at xemaps.com
Thu Mar 29 07:04:16 EDT 2007


Mandy Chung wrote:

>
> Hi Joe,
>
> Your question was forwarded to me as I'm not on concurrency-interest.
>
> Can you elaborate what you have done?  I assume that you refer "lock" 
> as one of the java.util.concurrent.locks you use.  Are you using the 
> java.util.concurrent.locks class or using your custom lock?
>
> Thanks
> Mandy
>
> Joe Seigh wrote:
>
>> I was using ThreadMXBean to compare the lock usage of some collections,
>> lock based and lock-free.  The lock-free one I wrote spends most of its
>> time blocked on locks according to ThreadMXBean.   So if you are *not*
>> using locks, how do you figure out which locks you are blocking on?
>>
>>  
>>
>
>
The locks are whatever ThreadMXBean measures.   I suspect it is the GC 
which appears to be using
conventional synchronization to park threads.   I threw in the 
ThreadMXBean stuff in the testcase
I was running.  Lock-free algorithms tend to be memory intensive and I 
one I wrote is especially
so since it's using hashmaps and copy on write.  Usually I put in a 
semaphore on writes in lock-free
situations to put a bound on memory usage.   This isn't too easy in Java 
since the GC doesn't really
have a good interface here.  You really need a listener interface, not 
ReferenceQueue which is
set up to avoid running any user code on the GC thread.  You can use a 
polling thread there
but running an extra thread in library code is awkward, otherwise GC 
would have done it
to provide a listener interface.

Testcase output below.  Timings are in milliseconds and except for elapsed
time, are cumulative thread timings.   sum is an internal sanity check.
Additional stuff for XmemQueue are just counters to see what actually
happens.  nodes is the count of  non GC'd collector nodes at the end
of threads execution and nodes2 is count of same after a call to
System.gc() to verify I don't have a memory leak.

Source code without ThreadMXBean stuff is here
SourceForge.net: Lock-free synchronization primitives 
<http://sourceforge.net/projects/atomic-ptr-plus/>

thread count = 20
loop count   = 5000

starting ConcurrentLinkedQueue ...
elapsed time   = 1211 msec
total time     = 6545
system time    = 170
user time      = 150
blocked time   = 3964
blocked count  = 31
waited time    = 0
waited count   = 0
sum           = 249950000 (expected 249950000)

starting LinkedBlockingQueue ...
elapsed time   = 1162 msec
total time     = 8703
system time    = 100
user time      = 100
blocked time   = 0
blocked count  = 0
waited time    = 8339
waited count   = 28
sum           = 249950000 (expected 249950000)

starting Synchronized LinkedList ...
elapsed time   = 2434 msec
total time     = 29010
system time    = 1482
user time      = 650
blocked time   = 26259
blocked count  = 149748
waited time    = 0
waited count   = 0
sum           = 249950000 (expected 249950000)

starting XmemQueue ...
elapsed time   = 7821 msec
total time     = 110886
system time    = 1341
user time      = 1311
blocked time   = 95421
blocked count  = 1091
waited time    = 0
waited count   = 0
sum           = 249950000 (expected 249950000)
tries    = 200229
retries  = 228
notries  = 226
noswaps  = 3
nodes    = 85032
nodes2   = 0



--
Joe Seigh



More information about the Concurrency-interest mailing list