Synchronized

[David Ulicny]

Does the synchronized keyword any impact on performance?

[Ernest Friedman-Hill]

At the very least, it compiles to a pair of bytecodes: monitorenter and monitorexit. It used to be that the implementations of these were rather expensive; that's much less true today, especially when the current thread already hold the lock on the given object.

[Alexandru Popescu]

Theoretically yes, as the threads racing for a lock are paused. Practically the syncronized blocks have been very optimized and now I can say that there are no big performance penalties.

./pope

[David Ulicny]

We are using WAS 5.0, it has JVM 1.3.1, it's running on iSeries. Is it also optimized or are these optimizations in the higher version of JVM?

[Alexandru Popescu]

Originally posted by David Ulicny:
We are using WAS 5.0, it has JVM 1.3.1, it's running on iSeries. Is it also optimized or are these optimizations in the higher version of JVM?

I think they are already in place. A big improvement was brought also in 1.4 (you can hardly see 'em ).

./pope

[Henry Wong]

Originally posted by David Ulicny:
Does the synchronized keyword any impact on performance?

Yes... we actually spend a whole chapter on performance. And a large part of it is on synchronization.

Basically, there are two impacts on performance due to synchronization. First, is the cost to execute the synchronization primatives. And second, the blocking of the thread because of the synchronization. To improve the second, you have to change your algorithm -- which is the discussion topic of the free online chapter. (http://www.oreilly.com/catalog/jthreads3/)

To improve the first, you have to completely remove the synchronization... but as discussed in the performance chapter, it is not that large of a problem. Simply, if the lock is uncontended, it is in the order of nanoseconds. If the lock is contended, it is in the order of milliseconds. Which depending on the size of the synchronization block, can be a really insignificant.

Henry

[Henry Wong]

Originally posted by Ernest Friedman-Hill:
At the very least, it compiles to a pair of bytecodes: monitorenter and monitorexit. It used to be that the implementations of these were rather expensive; that's much less true today, especially when the current thread already hold the lock on the given object.

I agree... synchronization costs in terms of time to acquire and release locks has been greatly improved in recent JVMs.

Henry

[Mr. C Lamont Gilbert]

its not the keyword that has the impact but the whole design of a thread safe program that has the impact. Synchronized keyword is just one part of that.

I would add that you do not synchronize because you want to, you synchronized because you have to. Therefore, the question is moot.
[ October 29, 2004: Message edited by: CL Gilbert ]

[Alexandru Popescu]

Indeed. We were not talking about a keyword impact on performance - as for the moment I do not see one doing this. People seem to remember the first discussions on synchronization from the time when doing it increased the time by 8 (or so). We were trying to present the now-a-days facts of the JVMs

./pope

[Surasak Leenapongpanit]

I think, this "To synchronize or not to synchronize" article may help you.