Synchronized vs Lock performance

Overview

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

These are the times to perform 25 million locks/operation in seconds. Lower numbers are better. Different system will get different results, so these should be taken as a relative performance.

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

SynchronizedVsLockTest.java

Conclusion

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.

Related articles

Java Concurrency in practice - Favours locks for performance, otherwise suggest synchronized be used if not an issue. States Lock are much faster for Java 5.0, slightly faster for Java 6
Java Performance: synchronized() vs Lock - Favours synchronized, based on a micro-benchmark. Compares one and two threads
java.util.concurrent ReentrantLock vs synchronized() - which should you use? - Favours synchronized on technical arguments
Synchronized vs. Lock vs. fair Lock - Compares locks based on fairness rather than performance
synchronized vs custom locking: Java synchronization performance - Determines that Locks were 5x faster for Java 5.0
Java synchronized block vs ReentantLock performance - Compares synchronized vs Locks with 10 threads, concludes Locks are significantly faster (about 5x) Not clear if this test was done with Java 5.0 also
Performance of ReentrantLock and Synchronized - Compares different numbers of threads and concludes synchronized is only fastest for one thread

Comments

  1. great article for java enthusiasts like us

    ReplyDelete
  2. @lava, What makes this topic interesting is the variety of opinions on the subject.

    ReplyDelete
  3. Uh, but why don't you explain what the numbers in the table actually means?

    ReplyDelete
  4. @flylang, Thank you. You can probably guess, but you shouldn't have to. I will add this to the article.

    ReplyDelete
  5. I just wonder, what is the point of these micro benchmarks? Are you developing your own HPC collections framework?

    A long time ago I did the same - micro benchmarks. But lately more comprehensive benchmarks seem more appropriate.

    ReplyDelete
  6. @JAlexoid, I would agree that if you have a specific use case, benchmarking it is a far better test.

    The use of a micro-benchmark is to determine how much difference its likely to make using synchronized and Locks. It is quite likely you will decide the simplicity of synchronized makes it a better choice as it performs more than well enough.

    ReplyDelete
  7. Agree with people here , its a usecase 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.

    Javin
    How Synchronization works in Java

    ReplyDelete
  8. Great article with an excellent sample program. I just ran it on my i7 laptop and got the following for the 64 thread result.
    2x synchronized {} with 64 threads took 10.727 seconds

    So my question is why do the experts say "avoid synchronization at all costs". The test program is executing 50 * 1000 * 1000 (50,000,000) loops and doing two synchronized operations inside of each loop. According to my calculations this means that on average it takes 0.000000107 seconds to perform each synchronized block. To me this is insignificant. Help me understand if I'm wrong.

    ReplyDelete
  9. I would say; only some experts say avoid synchronization/locking, some experts have long memories and what was true in Java 1.4 or 5.0 may not be true in Java 6 or 7.

    Locking/synchronization can make a dramatic relative difference if you are protecting a simple operation (in which case using the AtomicXxxxxx classes might be an option) While it might make x++ much, much slower, it can be very small in the overall application.

    What is insignificant depends on the application. I have a library Java Chronicle which can send persisted messages between processes in around 50 to 200 ns. In this situation adding a lock of 100 ns would significantly slow this down (it is lock free) but if you are performing an operation which takes say 10 micro-seconds, a lock is likely to be trivial.

    ReplyDelete

Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

System wide unique nanosecond timestamps

Unusual Java: StackTrace Extends Throwable