Advanced multithreading: Lock strategy

---

Tips ： The following is the main body of this article ,Java The series of learning will be continuously updated

1. Exclusive and shared locks

Shared lock ：Share Lock (S lock ), ‘ read ’ Operations are not mutually exclusive ,‘ Write ’ Operations are mutually exclusive ,‘ read + Write ’ Operations are mutually exclusive .
An exclusive lock ：exclusive Lock (X lock ), All operations are mutually exclusive .

If in a certain scene “ Read more than a writing ”, The efficiency of using read-write lock is very high .
Because only read data , Multiple threads read a data at the same time , It will not cause thread insecurity . Only modifying the same data will make the thread unsafe

Java Read write lock in ：

ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
Lock readLock = readWriteLock.readLock();
Lock writeLock = readWriteLock.writeLock();

// readLock They are not mutually exclusive ,readLock and writeLock They are mutually exclusive ,writeLock They are mutually exclusive 

readLock.lock(); //  The main thread is added to the read lock 

Thread t = new Thread() {
    
	@Override
	public void run() {
    
		readLock.lock(); //  The main thread has grabbed the read lock , The sub thread can still grab the lock 
		//writeLock.lock(); //  Writing a lock is not enough 
		System.out.println(" A child thread can also successfully apply a read lock ");
	}
};
        
t.start();

Back to directory …

2. Reentrant locks and non reentrant locks

Reentrant lock ： A thread already holds lock1 In case of lock , Allow to get lock1 The same lock .
synchronized、ReentrantLock Are reentrant locks .

public static void main(String[] args) {
    
	Object lock = new Object();
	synchronized (lock) {
       // main  The thread is already on  lock  Locked 
		synchronized (lock) {
       // main  Thread again on  lock  Request lock （ In the locked state ）
			System.out.println(" If you print it here, it means  sync  A lock is a relocatable lock ");
		}
	}
}

Back to directory …

3. Fair and non-fair locks

Fair lock ： Multiple threads acquire locks in the order in which they apply for locks , That is to say , If a thread group , It can ensure that every thread can get the lock .
for example ：ReentrantLock You can pass in fair = true / false To control whether it is fair , The default is unfair .（fair = true, Synchronization queue used FIFO）
Not fair lock ： The way to acquire locks is random , There is no guarantee that every thread can get the lock , Some threads will starve , I can't get the lock , for example ：synchronized

summary ： The performance of non fair lock is higher than that of fair lock , More reusable CPU Time for

Back to directory …

4. Optimistic lock and pessimistic lock

The lock is not in the real sense , But in the case of multithreading , Evaluate concurrency to design locks ：
Optimism lock : When multiple threads get the same shared resource , Optimistic that they will not modify the data , So don't lock it . Or only a few threads modify the data , You can use lightweight locking for concurrency control .cas It's the optimistic lock , Data synchronization is ensured by atomicity .
Pessimistic locking : Whether or not multiple threads frequently modify the same shared resource , Mutual exclusion must be used ( lock lock) For concurrency control . Such as synchronized、ReentrantLock

summary ： Pessimistic lock is suitable for scenarios with many write operations , Optimistic lock is suitable for scenarios with more reading operations , The throughput of optimistic locks will be higher than that of pessimistic locks

What is? CAS?

CAS: Full name Compare and swap, Literally :” Compare and exchange “, One CAS The following operations are involved ：
Let's assume that the raw data in memory V, Old expectations A, New values that need to be modified B.
 1. Compare A And V Whether it is equal or not .（ Compare ）
 2. If it's equal , take B write in V.（ In exchange for ）
 3. Whether the return operation is successful
principle ： Go back and forth ( operation + Judge ： actual value == Expected value ？ End of cycle ： Continue to operate + Judge )

CAS Application ：
 1. Realization java.util.concurrent.atomic The atomic class under the package
  AtomicInteger atomicInteger = new AtomicInteger(0);
  // amount to i++
  atomicInteger.getAndIncrement();
 2. Spin lock is realized

Back to directory …

5. Mutexes and spinlocks

In terms of implementation principles ：

Mutex（ The mutex ） Belong to sleep-waiting Type of lock . For example, there are two threads on a single core machine （ Threads A And thread B）. Assuming that thread A Want to get a critical area lock , At this point, the lock is being locked by the thread B Held by , So thread A Will be blocked , At this point, the thread A In the waiting queue , Wait for thread B Release the lock to wake up the thread A.
and Spin lock（ spinlocks ） Applicable to multi-core computers , It belongs to busy-waiting Type of lock , If the thread A Lock not requested , Will not cause thread scheduling （ Give up CPU）, Instead, it keeps cycling there to see if the owner of the spin lock has released the lock , Keep making lock requests , Until I get this lock .

The use of spinlocks ：

 ① We should use spin lock carefully , Spin lock only in The kernel can be preemptive or SMP( Multicore ) We really need to , In the single CPU And under the non preemptive kernel , Spin lock operation is null operation .
 ②“ spinlocks ” The role of is In order to solve the mutually exclusive use of a resource . Because spin locks don't cause the caller to sleep ( Thread scheduling ), So spin lock is much more efficient than mutex .
 ③ The spin lock has been occupying CPU, He didn't get the lock , Has been running （ The spin ）, So it takes up CPU, If you can't get the lock in a short time , This will undoubtedly make CPU Low efficiency . therefore Spin lock is more suitable for the case that the lock holder holds the lock for a relatively short time .
 ④ Trying to get a spin lock recursively is bound to cause a deadlock : The holding instance of the recursive program is in the second instance loop , To try to get the same spin lock , This spin lock will not be released .

Back to directory …

---

summary :
Tips ： Here is a summary of the article ：
The above is today's learning content , This article is about Java Multithreaded learning , Recognize different locking strategies , And the application scenarios of these strategies . After that, the learning content will be continuously updated ！！！