Link Details

""The moral here," said Manson, "is don't avoid synchronization. When doing tricky things to avoid synchronization, you end up writing really bad code.""

I'm afraid I have to disagree. They may be correct in that synchronization is not expensive when you don't have multiple threads competing for the lock (I don't know myself, I haven't run those numbers), but in those scenarios there really is no need for synchronization in the first place. When you do have contention for the resource, it should be obvious that the time goes up relative to the number of threads that need the resource at one time. And of course overly synchronized code is prone to deadlocks, which is even worse than poor performance. So yes, if there is some "tricky" thing you can do to avoid synchronization in a commonly used block of code, you probably should do it.

< So yes, if there is some "tricky" thing you can do to avoid synchronization
< in a commonly used block of code, you probably should do it.

Actually, the JIT is smart enough to do most of this for you, especially in Java 6. I know it can optimize away unused synchronizations; synchronization avoidance definitely strikes me as the sort of thing it should be capable of. I haven't actually tested for this, but then, testing optimizations in a compiler is always a dicey matter, especially where the indeterminacy of threads comes into play.

Again, its not unused synchronizations that are problematic. Its those that cause multiple threads to get in a blocked state because they are waiting for another to complete.

Hi all,
Actually, I found that in practice on big java server applications that 64 bit on identical hardware is usually a bit slower, because memory consumption is higher (between 30-50%) and therefore given the same amount of memory, the GC will run more often.

The influence of Memory consumption on performance is often underestimated.
That is hopefully going to change because new tools will make it easier to analyze the memory consumption of Java applications.
See also my post at http://kohlerm.blogspot.com/2008/05/analyzing-memory-consumption-of-eclipse.html

Regards,
Markus