Why are synchronize expensive in Java?

by

Maybe it’s not as bad as you think

It used to be terrible (which is possibly why you read that it was “very expensive”). These memes can take a long time to die out

How expensive is synchronization?

Because of the rules involving cache flushing and invalidation, a synchronized block in the Java language is generally more expensive than the critical section facilities offered by many platforms, which are usually implemented with an atomic “test and set bit” machine instruction. Even when a program contains only a single thread running on a single processor, a synchronized method call is still slower than an un-synchronized method call. If the synchronization actually requires contending for the lock, the performance penalty is substantially greater, as there will be several thread switches and system calls required.

Fortunately, continuous improvements in the JVM have both improved overall Java program performance and reduced the relative cost of synchronization with each release, and future improvements are anticipated. Further, the performance costs of synchronization are often overstated. One well-known source has cited that a synchronized method call is as much as 50 times slower than an un-synchronized method call. While this statement may be true, it is also quite misleading and has led many developers to avoid synchronizing even in cases where it is needed.

Having said that – concurrent programming can still be slow, but not so much of it is purely Java’s fault now. There is a trade-off between fine and coarse locking. Too coarse is obviously bad, but it’s possible to be too fine too, as locks have a non zero cost.

It’s important to consider the particular resource under contention. Mechanical hard disks are an example where more threads can lead to worse performance.

More Related Contents:

  1. What does ‘synchronized’ mean?
  2. Avoid synchronized(this) in Java?
  3. Difference between volatile and synchronized in Java
  4. Is there an advantage to use a Synchronized Method instead of a Synchronized Block?
  5. Synchronizing on String objects in Java
  6. Java synchronized static methods: lock on object or class
  7. Java synchronized method lock on object, or method?
  8. Is HttpSession thread safe, are set/get Attribute thread safe operations?
  9. Java Synchronized Block for .class
  10. Synchronization of non-final field
  11. Happens-before relationships with volatile fields and synchronized blocks in Java – and their impact on non-volatile variables?
  12. Static versus non-static lock object in synchronized block
  13. Should getters and setters be synchronized?
  14. If I synchronized two methods on the same class, can they run simultaneously?
  15. Is ConcurrentHashMap totally safe?
  16. In Java critical sections, what should I synchronize on?
  17. What is the difference between synchronized on lockObject and using this as the lock?
  18. What is the difference between a synchronized method and synchronized block in Java? [duplicate]
  19. do we need volatile when implementing singleton using double-check locking
  20. Why can’t Java constructors be synchronized?
  21. Should you synchronize the run method? Why or why not?
  22. Java volatile modifier and synchronized blocks
  23. Java Multithreading concept and join() method
  24. Difference between Synchronized block with wait/notify and without them?
  25. Do two synchronized methods execute simultaneously
  26. What is the reason why “synchronized” is not allowed in Java 8 interface methods?
  27. Is synchronized inherited in Java?
  28. Learning Java, use of synchronized keyword
  29. If a synchronized method calls another non-synchronized method, is there a lock on the non-synchronized method
  30. Side effects of throwing an exception inside a synchronized clause?

Leave a Comment