Summary and explanation of display lock and built-in lock of Java multithreading

Summarize the display lock and built-in lock of multithreading

Java has built-in locks implemented through synchronized and display locks implemented by reentrantlock. These two locks have their own advantages and complement each other. This article is a summary.

*Synchronized*

The built-in lock is implicit. Entering the synchronized modified code will obtain the lock, and exiting the corresponding code will release the lock.

signal communication

The communication method used with synchronized is usually wait(), notify().

The wait () method will immediately release the current lock and enter the waiting state. The execution can not continue until the corresponding notify and re obtain the lock; Notify () will not release the lock immediately. It will not be released until the thread where notify () is located executes all the code in the synchronized block. Verify with the following code:

Operation results:

It can be seen that the read thread starts running. After the wait, the write thread obtains the lock; After the write thread goes out of the synchronization block instead of notify, the read thread ends the wait, that is, obtains the lock. Therefore, notify will not release the lock, but wait will release the lock. It is worth mentioning that notifyAll () notifies all threads in the waiting queue.

code

The coding mode is relatively simple and single. It does not need to be displayed to obtain and release the lock, which can reduce the error of forgetting to release the lock due to carelessness. The usage mode is as follows:

flexibility

1. When the built-in lock enters the synchronization block, it adopts the strategy of unlimited waiting. Once it starts waiting, it can neither be interrupted nor cancelled, which is prone to hunger and deadlock. 2 When a thread calls the notify method, it will randomly select a thread in the waiting queue of the corresponding object to wake it up instead of FIFO. If there are strong fairness requirements, such as FIFO, it cannot be met

performance

Synchronized in jdk1 5 and before, the performance (mainly refers to throughput) is poor, and the scalability is not as good as reentrantlock. However, after JDK1.6, the algorithm for managing built-in locks has been modified, so that the performance of synchronized is not different from that of standard reentrantlock.

*reentrantlock*

Reentrantlock is a display lock, which needs to be displayed for lock and unlock operations.

signal communication

The mode of passage matched with reentrantlock is condition, as follows:

Condition is bound to lock, and lock must be used Newcondition() to create a condition. From the above code, it can be seen that the communication mode and condition that can be realized by synchronized can be realized, and the code with similar functions is written in the same line. The advantage of condition is that it can establish different conditions for multiple threads, such as object read / write conditions and queue empty / full conditions. This feature is used in arrayblockingqueue in JDK source code:

code

Compared with synchronized, it is more complex, and you must remember to release the lock in finally rather than elsewhere, so as to ensure that the lock can be released even if an exception occurs.

flexibility

1.lock. Lockinterruptibly () enables threads to respond to interrupts while waiting for locks; lock. Trylock () can make the thread stop waiting after waiting for a period of time if it has not obtained the lock, instead of waiting all the time. With these two mechanisms, we can better formulate the retry mechanism to obtain the lock, rather than blindly waiting, which can better avoid hunger and deadlock problems

2. Reentrantlock can become a fair lock (non default). The so-called fair lock is the FIFO of the waiting queue of the lock. However, fair lock will bring performance consumption. If it is not necessary, it is not recommended to use it. This is similar to the reason why the CPU reorders instructions. If the instructions are forcibly executed according to the writing order of the code, many clock cycles will be wasted and the maximum utilization will not be achieved

performance

Although the performance of synchronized and standard reentrantlock is not different, reentrantlock also provides a non mutually exclusive read-write lock,

That is, it does not force at most one thread to hold a lock at a time. It will avoid "read / write" conflicts and "write / write" conflicts, but it will not exclude "read / read" conflicts,

Because "read / read" does not affect data integrity, multiple read threads can hold locks at the same time. In this way, the performance will be greatly improved in the case of high read and write.

The following two types of locks are used to implement thread safe LinkedList:

Read / write lock test code:

Sync lock test code:

result:

It can be seen that read-write locks are indeed better than pure broken mutex locks

summary

The biggest advantage of the built-in lock is that it is simple and easy to use. The biggest advantage of the display lock is that it has rich functions. Therefore, if the built-in lock can be used, the built-in lock shall be used. When the built-in lock function cannot be met, the display lock shall be considered.

The above is all about the summary and detailed explanation of Java multithreaded display lock and built-in lock in this paper. I hope it will be helpful to you. Interested friends can continue to refer to this website:

Three methods and examples of Java multithreading interrupt mechanism

On the advantages of Java multithreading and code examples

Java uses future to get multithreading results in time