In Java, both synchronized and ReentrantLock use unfair locks by default, and the reasons for using unfair locks are the same, both to improve program performance. So why can unfair locks improve performance? Let's take a look next.
unfair lock
Unfair lock: The order in which each thread acquires locks is random and does not follow the first-come-first-served rule. Any thread may directly acquire and own a lock at a certain moment.
This is like going to refuel. When I arrived at the gas station, I found that someone was refueling in front of me, so I swiped the vibrato in the car. Happily scrolling on Douyin in the car. However, another car came to the gas station at this time, and found that there was a free oil gun, so he filled up the oil before Brother Lei. The oil guns here are locks, and the oil guns are not obtained in the order of arrival, which is an unfair lock.
fair lock
Fair lock: The order in which each thread acquires the lock is acquired in the order in which the threads access the lock, and the front thread always acquires the lock first.
This is like queuing up to pass the toll booth on the expressway. All the cars have to wait in line to pass, and the first car to pass through the toll booth first.
performance comparison
The performance test results of fair locks and unfair locks are as follows. The following test data comes from "Java Concurrent Programming Practice":
It can be seen from the above results that the throughput rate (the average rate of successfully acquiring locks per unit time) using unfair locks is much higher than that of fair locks.
performance analysis
Although the above test data illustrates the results, it does not explain why the performance of unfair locks is higher? So, next, we get the answer to this question by analyzing fair locks and unfair execution processes.
Fair Lock Execution Process
When acquiring a lock, first add the thread itself to the end of the waiting queue and sleep. When a thread runs out of locks, it will wake up the thread at the head of the waiting queue to try to acquire the lock. The order in which the locks are used is also the sequence in the queue. In order, in the whole process, the thread will switch from the running state to the sleeping state, and then restore from the sleeping state to the running state, but every time the thread sleeps and resumes, it needs to convert from the user state to the kernel state, and this state transition is relatively Slow, so the execution speed of the fair lock will be slower.
User Mode & Kernel Mode
User Mode: When a process is executing the user's own code, it is said to be in the user running state. Kernel Mode: When a task (process) executes a system call and falls into the execution of the kernel code, we call the process in the kernel running state. At this time, the processor is executed in the kernel code with the highest privilege level.
Why separate kernel mode and user mode?
Assuming that there is no distinction between kernel mode and user mode, the program can read and write hardware resources at will, such as reading and writing and allocating memory at will. In this way, if the programmer accidentally writes inappropriate content to a place where it should not be written, it is likely to will cause the system to crash.
With the distinction between user mode and kernel mode, the program will perform a series of verifications and inspections when performing a certain operation, and then it can operate resources normally after confirming that there is no problem, so that you will not worry about accidentally turning the When the system is broken, that is, with the distinction between the kernel mode and the user mode, the program can run more safely, but at the same time, switching between the two modes will cause a certain performance overhead.
Unfair Lock Execution Process
When a thread acquires a lock, it will first try to acquire the lock through CAS. If the acquisition is successful, it will directly own the lock. If it fails to acquire the lock, it will enter the waiting queue and wait for the next attempt to acquire the lock. The advantage of this is that the acquisition of locks does not need to follow the first-come-first-served rule, thereby avoiding the operation of thread sleep and recovery, thus speeding up the execution efficiency of the program.
For example, I went to a small business hall to handle the business of network transfer. After I went there, I found someone in front of me doing business, so I told the lady in front (handling the business), "take a break at the door, you will finish the business later, please go to Call me at the door", the young lady is also nice, so she agreed immediately.
But there is a period of idle time between when the lady calls me after finishing the business, and when I return to the counter to handle the business, which is the same as the idle time between waiting for threads in the queue to wake up and resume execution. , And in this free time, another old Li came to the business hall to pay the phone bill. After Lao Li paid the phone bill, I just came back and can handle business directly. This is a "triple win" situation.
Lao Li doesn't have to wait in line behind me to pay the phone bill, and I don't have to wait for Lao Li to pay the phone bill before going through the transfer process. Moreover, the efficiency of the salesperson's business handling has been improved within the unit time, and she can go home early. It is the so-called "triple win". Perform more tasks in a shorter time, which is the advantage of unfair locks .
Summarize
In this article, we introduced the definitions and execution processes of fair locks and unfair locks. From the details of the execution processes of the two, we can see that because unfair locks do not need to be executed in (sequential) order, subsequent locks can also directly try to acquire locks. There are no steps to block and resume execution, so it will be more performant.