In the past I have followed this approach myself. But that is changing. If you want to future proof your code, don't use classic locks. Project Loom doesn't work with classic locks, and the java.nio package is has been re-written to remove classic locks:

> In Project Loom, there will be support for efficiently switching between fibers that use Java 5 locks (that is, the java.util.concurrent.lock package) but not native C locks. As a result, it is necessary to migrate all blocking code in the JDK over to Java 5 locks. So the legacy Socket API required reimplementation to achieve better compatibility with Project Loom.

See: https://blogs.oracle.com/javamagazine/inside-java-13s-switch...

> don't touch ReadWriteLocks

I am interested in references that back this statement

I was interested in this as well, and yes ReadWriteLocks are horrible[0]. Just using synchronized is a good default that performs well in most scenarios, StampedLocks are good too.

[0] https://blog.overops.com/java-8-stampedlocks-vs-readwriteloc...

About the blog - testing with more threads than cores could be quite misleading, also testing on dual/quad socket vs single one exhibits the effects on coherency traffic a lot more (compared to L3 talk)

Briefly:

- the lock has write a CAS on the =fast= read path, causing coherency traffic and a contention point between the readers. That's it the readers don't scale

- it's quite hard to use correctly, i.e. after read, determining the exclusive/write lock has to be acquired, the read lock has to be released 1st, the write lock acquired and the conditions that causes the grab to be rechecked

- Copy-On-Write should be a preferred solution for most cases, easy to understand and reason about. If not StampedLock is a better alternative.

StampedLocks performs much better than R/W locks.