Welcome to follow our wechat official account: Shishan100
My new course ** “C2C e-commerce System Micro-service Architecture 120-day Practical Training Camp” is online in the public account ruxihu Technology Nest **, interested students, you can click the link below for details:
120-Day Training Camp of C2C E-commerce System Micro-Service Architecture
First, write first
What is your understanding of AQS? I talked about how AQS works in Java and packages, and also indirectly explained how ReentrantLock works.
What is the difference between fair locking and unfair locking in Java concurrent packages?
Two, what is unfair lock?
Let’s talk about what an unfair lock is, but let’s go back to the picture below.
As shown in the figure above, thread 1 now locks, and thread 2 tries to lock, fails, and is in a waiting queue, blocking. Thread 1 then releases the lock, ready to wake up thread 2 to try again.
Note that thread 2 is still waiting in the queue and has not yet attempted to re-lock.
Unfortunately, however, something happened when a thread 3 came out of the way to bite gold! What happens when thread 3 suddenly tries to lock the ReentrantLock?
Very simple! Thread 2 hasn’t had time to try locking again. In other words, there is no time to try to re-execute the CAS operation to change state from 0 to 1. Thread 3 tries to change state from 0 to 1 with a direct CAS operation, and it succeeds!
Once the CAS operation is successful, thread 3 sets the variable “lock thread” to itself. Here’s a picture of the process:
Obviously somebody else thread 2 orderly queue to get the lock, the result you thread 3 not obey the rules, thread 1 just released the lock, indiscriminately, directly ran over to add the lock first.
This causes thread 2 to wake up and retry the CAS operation, which fails.
The reason is very simple! Because the CAS operation is trying to change the state from 0 to 1, the result is that the state is already 1, so the CAS operation must fail!
If the lock fails, thread 2 will remain in the queue waiting for thread 3 to release the lock before waking up. Thread 2 could not add the lock.
Here’s another example of thread 2’s helplessness:
The above locking strategy is called unfair locking!
If you use the default constructor to create a ReentrantLock object, the default lock strategy is unfair.
Under the unfair lock strategy, it is not necessary to say that the thread that queued first will get the opportunity to lock first, but various threads will preempt at will.
So what if you want to implement a fair locking strategy? It is as simple as passing a true when constructing the ReentrantLock object:
ReentrantLock lock = new ReentrantLock(true)
Let him use a fair lock. What does fair lock mean?
Three, what is a fair lock?
Let’s go back to the first diagram, where thread 1 has just released the lock, but thread 2 has not had time to re-lock.
Again, let’s say there’s a thread 3 that comes out of nowhere and wants to lock.
If it is a fair lock strategy, then thread 3 will not blindly lock like a fool.
He would judge first: Huh? Is there anyone waiting in line at AQS? If there are people in line, it means there is a brother in front of me who is trying to lock up.
If the AQS queue does have threads queuing, then THREAD 3 can’t preempt the lock like an idiot.
Because now we are a fair strategy, we have to queue up in the order of first come, first come, first come out of the queue to lock up!
Therefore, when thread 3 finds that there is a queue in the queue, it will obediently queue to the back of the queue, rather than rush to lock!
Similarly, the whole process is shown visually in the following diagram:
In the above queue, thread 3 will queue directly to the end of the queue according to the principle of fairness.
Then, thread 2 wakes up, doesn’t it? He will try again to CAS lock, at this time no one to rob him, he can of course lock success.
Thread 2 then changes state to 1 and sets the “lock thread” to itself. Finally, thread 2 dequeues itself from the wait queue.
The whole process is shown below:
This is a fair lock strategy, to lock the thread is all in accordance with the order of first come, in turn into the waiting queue queue, not blind random preemption lock, very fair.
Four, summary
Well, through drawing and text analysis, I believe we all understand what is fair lock, what is not fair lock!
However, it is important to remember that the default locking strategy in many Java packages is unfair, that is, the next thread may be locked first, and the first thread will be locked later.
In general, the unfair strategy is not a big problem, but you should be aware of this strategy, when developing, you need to consider and weigh whether to use a fair strategy or an unfair strategy.
What is volatile about Java concurrent interview Questions? How can Java 8 optimize CAS performance? What is your understanding of AQS? What are Fair locks and Unfair Locks for Concurrent Java interview questions? Optimization of read/write locks for microservices Registries in Java concurrent Interview questions **, ** stay tuned
END
If there is any harvest, please help to forward, your encouragement is the biggest power of the author, thank you!
A large wave of micro services, distributed, high concurrency, high availability of original series of articles is on the way
Please scan the qr code belowContinue to pay attention to:
Architecture Notes for Hugesia (ID: Shishan100)
More than ten years of EXPERIENCE in BAT architecture