Investigate Lock vs Synchronized performance about okhttp HOT 4 CLOSED

Dead links

http://blogs.sun.com/dave/entry/java_util_concurrent_reentrantlock_vs
http://lycog.com/concurency/performance-reentrantlock-synchronized/
http://www.ibm.com/developerworks/java/library/j-jtp10264/

Medium article (no access)

https://medium.com/javarevisited/synchronized-vs-reentrantlock-how-to-choose-cfb5306080e7

from okhttp.

2013 paper showing locks win for single threaded

https://fileadmin.cs.lth.se/cs/education/EDA015F/2013/Ch13-presentation.pdf

from okhttp.

A bunch of github issues for updating projects like pgjdbc/pgjdbc#1951

With a link to 2023 article https://www.mo4tech.com/comparison-of-synchronized-and-reentrantlock-performance-in-java.html Comparison of Synchronized and ReentrantLock performance in Java

There is no doubt that synchronized performs 20-30% worse than ReentrantLock, so should lock be used everywhere in your code that synchronized is used? No, if you think about it, ReentrantLock is a better substitute for almost any scenario that uses synchronized, so why does the JDK stick with this keyword? And there is absolutely no desire to scrap it.

from okhttp.

cc @swankjesse I think the only real way is to benchmark your app, with a known workload, before and after on a specific JVM and architecture. I don't think it's a one is faster than the other deal.

from okhttp.