DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Distributed Locking in Cloud-Native Applications: Ensuring Consistency Across Multiple Instances
  • Managing Distributed System Locks With Azure Storage
  • Solving Parallel Writing Issues in MuleSoft With Distributed Locking
  • Avoiding Prompt-Lock: Why Simply Swapping LLMs Can Lead to Failure

Trending

  • Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack
  • Architecting Petabyte-Scale Hyperspectral Pipelines on AWS
  • Why Good Models Fail After Deployment
  • The Third Culture: Blending Teams With Different Management Models

Synchronized vs. Lock Performance

There are a number of articles on whether synchronized or Locks are faster.

By 
Peter Lawrey user avatar
Peter Lawrey
·
Aug. 05, 11 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
42.3K Views

Join the DZone community and get the full member experience.

Join For Free

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 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

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.

 

From http://vanillajava.blogspot.com/2011/07/synchronized-vs-lock-performance.html

Lock (computer science)

Opinions expressed by DZone contributors are their own.

Related

  • Distributed Locking in Cloud-Native Applications: Ensuring Consistency Across Multiple Instances
  • Managing Distributed System Locks With Azure Storage
  • Solving Parallel Writing Issues in MuleSoft With Distributed Locking
  • Avoiding Prompt-Lock: Why Simply Swapping LLMs Can Lead to Failure

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook