Synchronization penalty for uncontested locks

Hello,

I keep reading about how synchronized code incurrs performance penalty for acquiring and releasing locks even when they are uncontested. However after making a test jsp page that compares a 10 million synchronized calls to an empty method to 10 million calls without any synchronization, I found that the penalty varied between 150ms and 250ms. And this is for acquiring 10 million locks! Am I missing something, or is the synchronization penalty really negligible?

Here's my test page:

Thank you,
Yuriy

It used to be much worse. Advances over the last few years have made a huge difference. But you always have to be careful of "microbenchmarks" like this -- they may not reflect real-world results.

I just got similar results putting this in a class and running it. 10,000,000 syncronized calls took around 215ms while 10,000,000 non-sync calls took between 15ms and 30ms.

I do agree with EFH that you must be careful about these things and always profile before and after you do any real optimizations.

Excuse my comments the code below

<code>
Object o = new Object();
Date startSync = new Date();
for (int i = 0; i < 10000000; i++) {
synchronized(o) {
emptyMethod();
}
}

</code>
you try to flag the ojbect o as a synchronized which is the same object
as if when saying
while ( condition){
1- int i = 0;
}
Does the above run the line 1 as long as the condition is true

I would like to see

<code>
Date startSync = new Date();
for (int i = 0; i < 10000000; i++) {
Object o = new Object();
synchronized(o) {
emptyMethod();
}
}
</code>

does it make a difference please notify me

Regards,
Alan

As many have noticed, with Java 5, uncontended synchronization is now incredibly minor -- barely noticeable if you do nothing else, and probably not noticeable if you are actually running code in synchronization.

Have said that, this actually improves with Java 6 (with probably some back port to later releases of 5). There is some work in progress to removed uncontended synchronization entirely. Apparently, for certain cases, it may be possible for the compiler to determine that the synchronization is not necessary at all.

Henry
[ April 04, 2005: Message edited by: Henry Wong ]

Originally posted by Henry Wong:
...There is some work in progress to removed uncontended synchronization entirely. Apparently, for certain cases, it may be possible for the compiler to determine that the synchronization is not necessary at all.

Henry

[ April 04, 2005: Message edited by: Henry Wong ]

If the compiler can do this is should tell the programmer because its probably a design flaw.

The speed of locks is only relevant to complain to the JVM writers to make it better. it does not affect the design of your program because you should always be locking as minimally as possible anyway. I guess its valid if you were considering locking and unlocking on each line of code...You shouldn't.

Alan, with the addition of creating a new object within the loop, the synchronized vs. unsyncrhonized times become around 325ms vs. 220 ms on average.

-Yuriy