Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to understand the reentrant lock in the Java lock. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Before we talk about reentering the lock, let's look at a piece of code.

What the above code wants to achieve is to use two threads to accumulate I a million times respectively, and finally hope that the value of I is 2 million. If you run the program according to the above code, you will find that the value of I can not reach 2 million in most cases. The reason is the problem of multi-thread data synchronization.

In order to solve the above problems, we naturally think of the synchronized keyword, through a simple modification of the program, such as the following figure, the red box is the part of the program change:

The function of the synchronized keyword here is that when each thread tries to perform + + operations on I, it must first obtain the o object, an o object can only be held by one thread at a time, and other threads must wait for the thread holding the o object to perform the o object + operation and release the o object to try to get the o object. If the thread is successful, if the acquisition fails, the thread continues to wait. With the synchronized keyword, the otherwise parallelized operations are sequentially executed, that is, only one thread will + + I at a time, so the final value of I must be 2 million.

Synchronization control between multiple threads can be realized through the synchronized keyword. In addition to the above methods, Java provides us with many tool classes for concurrency control. Today, we are mainly talking about the reentrant lock ReentrantLock in Java, which is basically equivalent to the synchronized keyword.

To use a reentrant lock, a reentrant lock object must be obtained, and a reentrant lock object can be obtained by new a ReentrantLock.

The use of reentrant locks must explicitly specify locking and unlocking operations to enhance the readability of the program.

The same reentrant lock can only be held by the same thread lock at the same time, that is, when thread 1 successfully acquires the lock through the lock method, other threads who want to acquire the lock must wait for thread 1 to release the lock through the unlock method.

Reentrant locks support multiple locking and unlocking operations, but the number of locking and unlocking must be the same. If the number of locking and unlocking of a thread is greater than the number of unlocking, it will make the current thread occupy the relocked lock all the time, and other threads will never be able to acquire the lock, resulting in hunger. On the contrary, if the number of unlocking is greater than the number of unlocking, the program will throw an IllegalMonitorStateException exception.

The reentrant lock provides an interrupt response, which means that the request for the lock can be cancelled while waiting for the lock.

Through the code on the picture, it is easy to construct a deadlock phenomenon. When the lock value is 1, the thread will first try to obtain the reentrant lock lock1500ms and then try to obtain the reentrant lock lock2. On the contrary, if the lock value is not 1, the thread will first try to acquire the reentrant lock lock2500ms and then try to acquire the reentrant lock lock1. At this point, I open two new threads in the main function and set the value of lock to 1 and the other to 2.

When you run the program at this time, you will find that the program will never end because of the deadlock between the two threads.

Careful readers may have found that I use the lockInterruptibly () method instead of the lock () method when acquiring the reentrant lock, and as you can see from the method name, the lockInterruptibly () method supports interrupt response.

Next, I will interrupt the thread-2 thread through t2.interrupt () in the main thread, so that the reentrant lock 2 will be released, so that the thread-1 can be executed correctly, but the thread-2 is only interrupted and cannot be executed correctly, and only the methods in the finally block will be executed. The final output of the program is shown below:

In addition to interrupting the thread, we can also avoid deadlock and hunger by applying for a lock waiting time. The so-called lock application waiting time limit refers to specifying a maximum waiting time when applying for a lock. If the waiting time is exceeded and the lock is not acquired, the thread no longer waits and continues to execute.

To achieve the above effect, you only need to use the tryLock method to acquire the lock. This method will have a boolean return value. If the lock is acquired successfully, the return value will be true. If it fails, the return value will be false. This method has two overloaded methods, as shown in the following figure:

The above implementations are all unfair locks, and the so-called unfair means that the success rate of threads acquiring locks is random, some locks may always succeed in acquiring locks, while some threads may not acquire locks all the time, and those threads that cannot acquire locks will wait all the time, resulting in hunger.

In order to solve the above problems, reentrant locks support multiple threads to compete to acquire locks in a fair way, for example, there are two threads, and two threads try to acquire the same lock. If thread 1 successfully acquires the lock for the first time, it must be thread 2 rather than thread 1 that succeeds in acquiring the lock next time.

The implementation of a fair reentrant lock only needs to specify true in the construction parameters when the reentrant lock is acquired.

The above code opens two new threads in the main thread, and what each thread does is to circularly acquire the fairLock reentrant lock. Because fairLock is a fair reentrant lock, the T1 and T2 threads will acquire the lock alternately. The program running effect is shown below:

Although a fair reentrant lock can avoid deadlock, because an orderly thread queue must be maintained internally, the implementation cost of fair lock is high and the performance is relatively low.

About the Java lock in the reentrant lock how to understand how to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.