1.Lock interface locks are used to control how multiple threads access shared resources, in general, a lock prevents multiple threads from accessing shared resources concurrently (but some locks allow multiple threads to concurrently access shared resources, such as read-write locks). Before the lock interface appears, the Java program implements the lock function by the Synchronized keyword, and after Java SE 5, the Lock interface (and the associated implementation Class) is added to the package to implement the lock function, which provides synchronization capabilities similar to the SYNCHRONIZED keyword , you only need to explicitly acquire and release locks when you use them. While it lacks the convenience of implicitly acquiring a release lock (through synchronized blocks or methods), it has the synchronization characteristics that are not available in many synchronized keywords such as lock acquisition and release, interruptible acquisition lock, and timeout acquisition lock. The use of the Synchronized keyword implicitly acquires the lock, but it solidifies the acquisition and release of the lock, which is the first fetch and release. Of course, this approach simplifies the management of synchronization, but extensibility does not show the lock to get and release the good
2 Re-entry lock Reentrantlock Lock, as the name implies, is a lock that supports re-entry, which indicates that the lock can support a thread to repeatedly lock the resource. In addition, the lock also supports the choice of fair and non-fairness when acquiring locks. Recall the example (Mutex) in the Synchronizer section, taking into account the following scenario: When a thread calls the lock () method of a Mutex and then calls the lock () method again, the thread will be blocked by itself because the Mutex is implementing Tryacquire (int Acquires) method does not consider the scene in which the lock-occupying thread acquires the lock again, and false is returned when the Tryacquire (int acquires) method is called, causing the thread to be blocked. To put it simply, a mutex is a lock that does not support re-entry. While the synchronized keyword implicitly supports re-entry, such as a synchronized-modified recursive method, when the method executes, the execution thread acquires the lock multiple times after acquiring the lock, rather than the mutex because it acquires a lock. The next time a lock is acquired, it is blocking itself. Reentrantlock does not support implicit re-entry as the Synchronized keyword does, but when the lock () method is called, the thread that has acquired it has been able to call the lock () method again to get the lock without being blocked. There is a question about the fairness of a lock acquisition, if in absolute time, the request to obtain the lock first must be satisfied first, then the lock is fair, conversely, it is unfair. A fair acquisition lock, which is the longest waiting thread, is the first to acquire a lock, or it can be said that lock fetching is sequential. Reentrantlock provides a constructor to control whether the lock is fair. In fact, fair locking mechanisms are often not unfairly efficient, but not all scenarios are based on TPS as the only indicator, fair lock can reduce the probability of "starvation" occurring, the more waiting for the longer the request will be given priority to meet.
New Reentrantlock (); Lock.lock (); Try { finally { lock.unlock ();}
Implementing a re-entry re-entry means that any thread can acquire the lock again without being blocked by the lock after acquiring the lock, and the implementation of the feature needs to address the following two issues. 1) The thread acquires the lock again. The lock needs to identify whether the thread that acquires the lock is the thread that currently occupies the lock, and if so, succeeds in getting it again. 2) The final release of the lock. The thread repeats n times acquires the lock, and then the other thread acquires the lock after the nth release of the lock. The final release of the lock requires that the lock be counted for gain, the count indicates the number of times the current lock has been repeatedly fetched, while the lock is freed, the count is reduced, and when the count equals 0, the lock is successfully released. Non-fairness locks can cause threads to "starve", but very few threads switch, guaranteeing greater throughput. Therefore, the non-fairness lock is the default mechanism 3. A read-write lock mentions that locks (such as mutexes and Reentrantlock) are essentially exclusive locks that allow only one thread to access at the same time, while read-write locks allow multiple read threads to access at the same time, but when the write thread accesses, All read threads and other write threads are blocked. Read-write lock maintains a pair of locks, a read lock and a write lock, by separating the read and write locks, so that concurrency compared to the general exclusive lock has a great increase. In general, the performance of a read-write lock is better than locking it, because most scenarios read more than write. Read-write locks provide better concurrency and throughput than exclusive lock-in when reading more than writing. Java and the implementation of the contract to provide read-write locks is Reentrantreadwritelock, which provides the characteristics shown in table 5-8.
Locks in Java
