“This article has participated in the good article call order activity, click to see: back end, big front end double track submission, 20,000 yuan prize pool for you to challenge!”

The previous two articles covered synchronized and volatile in a comprehensive way. Synchronized satisfies atomicity, visibility, and ordering of access to shared resources by implicitly acquiring and releasing locks. By virtue of THE MESI protocol of the CPU, volatile satisfies the visibility and order of access to shared resources by both reading and writing the main memory. With these two keywords, it can satisfy most concurrent scenarios, but are they not enough? Of course not, from the beginning of this article, I will step into the legend of JUC, that first to understand the core interface Lock under JUC.

The birth of Lock

Volatile is a very simple but fragile synchronization mechanism that provides better performance and scalability than locking in some cases, and can be used in very limited scenarios.

Synchronized is a bit heavier than volatile, but provides more functionality, but has drawbacks.

  • One thread acquires the corresponding lock, and the other blocked threads wait indefinitely unless the thread task completes or an exception is interrupted.
  • In read-write scenarios, the read-write is also mutually exclusive for locks.
  • Cannot sense whether the thread has acquired the lock.
  • There is no mechanism for releasing locks by timeout, and there is no mechanism for releasing locks manually.

To address the issues raised above, the well-known Doug Lea developed components used in concurrent scenarios, the concurrent package java.util.concurrent, which includes thread pools, blocking queues, timers, synchronisers, concurrent collections, and, of course, the core component Lock.

Lock implementations provide more extensive locking operations than can be obtained using synchronized methods and statements.

The first sentence of the Java source code introduction to Lock, as shown above, makes it clear that Lock provides a wider range of Lock operations than synchronized, which is to say, more powerful. Indeed, since Java5, the emergence of Lock has addressed some of synchronized’s weaknesses and made it more flexible to use.

Two, Lock brief

A Lock is an interface that defines abstract methods for releasing and acquiring locks. See the figure below.

Defined as an interface means that this is a standard set of specifications that implement many types of locks based on Lock, as shown in the figure below.

2.1 already

Use AQS to achieve a reentrant lock, belongs to the mutex lock. As you can see clearly from the UML class diagram, it is the only class that implements the Lock interface. The so-called reentrant, after the thread acquired the lock, again need not block, but directly on the lock counter +1. It supports lock interruption, including fair lock and non-fair lock two implementations.

2.2 ReentrantReadWriteLock

Reentrant read-write locks, as you can clearly see from the UML class diagram, are implemented

The ReadWriteLock interface provides two abstract methods, one ReadLock and the other WriteLock, as shown in the figure below. Both methods return the Lock interface.

Read/write locks Are applicable to the scenarios with more read and less write services. The following principles apply to:

  • Read is not mutually exclusive
  • Read and write the mutex
  • Write about a mutex

All concurrent writes are mutually exclusive.

2.3 StampLock

This lock is special and is a new locking mechanism introduced in JDK8. Is an improvement on read/write locking. ReentrantReadWriteLock Is mutually exclusive in read/write scenarios. If there are too many read/write threads, the write threads may fail to obtain the lock for a long time and become hungry. The implementation of StampLock is based on an infinite loop trial-and-error strategy similar to the CAS operation. The specific implementation is the CLH lock, which is a spin lock that guarantees no starvation and ensures the order of FIFO services.

Hey, man, don’t panic! Leave a like and comment. Welcome to the column face interview don’t panic | Java concurrent programming, a raise don’t have to worry about the interview. Also welcome to pay attention to me, must do a long more good man.