Locking is usually considered to ensure thread safety in multi-threaded high concurrency scenarios in JAVA. But in special scenarios, we can also use thread-safe objects provided by the java.util.concurrent package to avoid locking and achieve high efficiency.

However, these thread-safe objects only refer to thread-safe operations for atomicity. If multiple method calls at the same time can not guarantee thread-safe, only locking can be considered. Here's a list: Suppose we use java.util.concurrent.ConcurrentLinkedQueue as an object to get elements in the queue in a multi-threaded high concurrency scenario, we can call poll() directly, and thread security can be guaranteed without locking. If we need to determine whether the queue is empty first when we get it. Then get, that is, call the isEmpty() method first, and then call the poll() method, this situation can not guarantee thread safety, because here is a two-step operation, can not guarantee atomicity.

ReentrantLock is also a way to lock multithreaded concurrency, which is often compared with synchronized. Let me sort it out briefly as follows:

1. Contrast from the angle of using method

1. ReentrantLock must release the lock manually, synchronized without consideration (abnormal automatic release of the lock)
2. ReentrantLock can try to lock trylock
3. ReentrantLock can also call the lock Interruptibly method to respond to the thread interrupt method
4. ReentrantLock can specify a fair lock Lock lock = new ReentrantLock(true)

2. Performance comparison

1. Before JDK 1.5, synchronized performance was slightly lower than ReentrantLock, including version 1.5 of JDK.
2. Since JDK 1.5, Java Virtual Machine has made many optimizations for synchronization, adding details such as bias lock, lightweight lock (mostly spin lock), and heavy lock. The performance is similar to that of ReentrantLock.

Let's analyze how ReentrantLock calls the lock Interruptibly method to respond to the thread interrupt method.

package com.reentranlock;

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * ReentrantLock You can also call the lock Interruptibly method to respond to the thread interrupt method
 *
 * @author Xiao Huige/Xiao Huige GE
 * <p>
 * 2019 10 August 2000, 15:30 p.m.
 */
public class ReentrantLockInterrupt {

	public static void main(String[] args) {
		Lock lock = new ReentrantLock();
		Thread thread1 = new Thread(() -> {
			lock.lock();
			try {
				System.out.println("thread1 start......");
				TimeUnit.SECONDS.sleep(Integer.MAX_VALUE);
			} catch (InterruptedException e) {
				System.out.println("thread1" + "interrupt......");
			} finally {
				lock.unlock();
				System.out.println("thread1 end......");
			}
		});
		thread1.start();

		Thread thread2 = new Thread(() -> {
			boolean status = false;
			try {
				status = lock.tryLock();
				System.out.println("thread2 start......");
				// You can respond to interrupt methods
				if (!status)
					lock.lockInterruptibly();
			} catch (InterruptedException e) {
				System.out.println("thread2" + "interrupt");
			} finally {
				if (status)
					lock.unlock();
				System.out.println("thread2 end");
			}
		});
		thread2.start();

		try {
			TimeUnit.SECONDS.sleep(5);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}

		thread2.interrupt();
	}

}

The test output is as follows:

Result analysis:

Thread1 and thread2 threads start, thread1 sleep for a long time, thread2 calls the lock Interruptibly method, can make a response to the thread interrupt method, and end directly. That's how ReentrantLock interrupts waiting threads. It's tough.

The above code is for reference only, if there is any mistake, please point out!!!

More dry goods, you are welcome to pay attention to and contact me. Looking forward to better communication with you, explore technology!!!