Microbenchmarks: Java Locks vs. Atomic

https://blog.tombert.com/posts/2025-03-04-lock-benchmark/

by tombert • 1 year ago

2 5 1 year ago

blog.tombert.com

Why does reentrantlock exist? Well, one reason is that it supports APIs like tryLock and multiple condition variables.

Why is it faster than synchronized? This is probably because (depending on your jvm) ReentrantLock is built on LockSupport.park, which is virtual thread aware, and synchronized is operating directly on the platform threads.

tombert2• 1 year ago

Fair enough; I had used it mostly because I wanted to ensure fairness conditions on some locked code.

That's interesting, I'll rewrite the tests with vanilla threads and update the page!

ETA:

Ok, I updated the tests to use vanilla platform threads, and surprisingly ReentrantLock is still faster. Here are the results:

    Total time for synchronized: 202ms, counter: 2000000
    Total time for atomic: 27ms, counter: 2000000
    Total time for lock: 58ms, counter: 2000000

charleslmunger2• 1 year ago

Did you use fair scheduling with ReentrantLock? That could account for a difference of intrinsic locks (synchronized) was a fair lock.

This type of benchmark is a pathological because the optimal scheduling policy is for one thread to starve all the others until it finishes, which is basically never what you'd want in a real project.

Microbenchmarks: Java Locks vs. Atomic

Related Stories