Performance Zone is brought to you in partnership with:

Peter is a DZone MVB and is not an employee of DZone and has posted 155 posts at DZone. You can read more from them at their website. View Full User Profile

Synchronized vs Lock performance

  • submit to reddit

There are a number of articles on whether synchronized or Locks are faster. There appear to be opinions in favour of either option. In this article I attempt to show how you can achieve different views depending on how you benchmark the two approaches.

I have included AtomicInteger to see how a volatile field compares.

What are some of the differences

The synchronized keyword has naturally built in language support. This can mean the JIT can optimise synchronised blocks in ways it cannot with Locks. e.g. it can combine synchronized blocks.

The Lock has additional method such as tryLock which is not an option for a synchronized block.

The test

As the JIT can optimise synchronized in ways a Lock cannot, I wanted to have a test which might demonstrate this and one which might "fool" the JIT.

In this test, 25 million locks were performed between each of the threads. Java 6 update 26 was used.
Threads1x synch1x Lock1x AtomicInteger2x synch2x Lock2x AtomicInteger
1 :0.9370.7860.4001.5321.4840.569
2 :2.7664.5970.6765.3986.3551.278
4 :3.9041.2670.6946.3302.6571.354
8 :3.8840.9531.0115.4182.0732.761
16 :3.2070.8691.1714.8171.6562.800
32 :3.2130.8531.2404.9151.6802.843
64 :3.3220.9211.2695.0491.6392.843

Note: It appears that Lock performs best with high numbers of threads. However this may because the performance approaches the single threaded performance. It may do this by avoiding contention and letting just one thread run for long periods of time.

The Code


In general, unless you have measured you system and you know you have a performance issue, you should do what you believe is simplest and clearest and it is likely to performance well.

These results indicate that synchronized is best for a small number of threads accessing a lock (<4) and Lock may be best for a high number of threads accessing the same locks.



Published at DZone with permission of Peter Lawrey, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Christopher Brown replied on Fri, 2011/08/05 - 3:05am

I generally opt for the simplicity of synchronized, however I do use ReadWriteLock instead in some cases (generally, when reads are more common that writes, and when the operation being performed -- especially "writes" -- can be time-consuming) instead of creating a threading bottleneck with synchronized.

 As I understand it, obtaining a lock is slower than obtaining a monitor for synchronized, but once you've got the lock, you can access the block at the same time as other readers which is interesting for non-trivial operations with high concurrency (work can be split), whilst still having exclusive access for modifications with the write lock.  In high-concurrency or slow operations, this is where synchronized is less effective.



Endre Varga replied on Fri, 2011/08/05 - 3:30am

Does the JIT perform optimizations with Lock just as with synchronized? I mean in certain cases the compiler might move instructions inside a synchronized block, does it do with Lock as well? Does Lock implement biased locking or adaptive spinning?

Artur Biesiadowski replied on Fri, 2011/08/05 - 4:38am

I'm suprised to see the performance degradation for locks with 2 threads (compared to 4 threads) and to see locks performing better than AtomicInteger. Do you have explanation why 2 threads are so slow for Lock on your machine ?

 On my machine, with client jvm, I got

1 0.667 2.452 1.345 3.603 4.242 2.197
2 7.542 3.786 1.812 12.510 4.742 2.279
4 7.474 3.925 1.791 11.957 4.711 2.295
8 7.408 3.330 1.808 12.831 4.687 2.313
16 7.297 3.336 1.792 11.513 4.739 2.276
32 8.110 3.291 1.805 12.206 4.750 2.329
64 7.407 2.672 1.784 12.191 4.700 2.325

 server jvm

1 2.160 1.894 1.310 3.585 3.179 2.030
2 4.001 2.803 1.706 4.102 3.679 2.322
4 6.193 2.752 1.715 5.159 3.619 2.236
8 6.320 2.490 1.699 5.595 4.602 2.273
16 8.075 2.497 1.707 5.687 4.288 2.291
32 5.978 2.427 1.708 6.073 4.345 2.263
64 7.933 2.428 1.732 5.896 4.164 2.284


Which is more what I would expect. Synchronization being very fast for uncontended case because of biased monitors, getting a lot worse for contended case. Locks being more or less agnostic to number of threeads, without so big degradation for 2 threads compared to 4 threads. AtomicInteger winning in  every multilthreading case, because you cannot get really faster than cmp&swap for such mulithreaded counter.

 So, open questions are:

- why atomic integer is so slow on your machine compare to locks - it is very counterintuitive

- why server jvm is so bad for uncontended synchronization compare to client jvm ?


Endre Varga replied on Fri, 2011/08/05 - 11:15am in response to: Artur Biesiadowski

"Synchronization being very fast for uncontended case because of biased monitors, getting a lot worse for contended case."

What I found counterintuitive is the 1 thread case. As far as I know, synchronized blocks use lightweight locking, and inflate the lock to an OS mutex only in the case of contention. How can Lock beat that? Do they use the same optimization?

Endre Varga replied on Fri, 2011/08/05 - 11:49am

"I have included AtomicInteger to see how a volatile field compares."

Btw, are you sure that AtomicInteger is implemented as a volatile field? Isn't it using a compiler intrinsic call with a native CAS instruction? I thought that volatiles are implemented by adding a memory barrier around it's access sites. And that memory barrier is something like "lock add [esp], 0".

Javin Paul replied on Mon, 2011/08/08 - 7:45am

In my opinion its a usecase or scenario which decides what to use obviously if you have just one reader and one writer, synchronized is the best choice because of clean and simple approach while in case of multiple Reader and Single writer , Lock interface can provide much better performance.

20 points about synchronization in Java


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.