9.Lock锁接口实现
- Lock的核心API
- lock 获取锁的方法,若锁被其他线程获取,则等待(阻塞)
- lockInterruptibly 在锁的获取过程中可以中断当前线程
- tryLock 尝试非阻塞的获取锁,立即返回
- unlock 释放锁
- 根据Lock接口的源码注释,Lock接口的实现,具备和同步关键字同样的内存语义,只不过可定制性更强大
-
ReentrantLock
独享锁、支持公平锁、非公平锁两种模式;可重入锁
5.png
import java.util.concurrent.locks.ReentrantLock;
public class ReentrantDemo1 {
//可重入锁:同一个线程和多次进入,加锁
private static final ReentrantLock lock=new ReentrantLock();
public static void main(String[] args) {
lock.lock();
try{
System.out.println("第一次获取锁");
System.out.println("当前线程获取锁的次数"+lock.getHoldCount());
lock.lock();
System.out.println("第二次获取锁");
System.out.println("当前线程获取锁的次数"+lock.getHoldCount());
}finally {
lock.unlock();
}
System.out.println("当前线程获取锁的次数"+lock.getHoldCount());
new Thread(()->{
System.out.println(Thread.currentThread()+"期望抢到锁");
lock.lock();
System.out.println(Thread.currentThread()+"线程拿到锁");
}).start();
}
}
/**
* 第一次获取锁
* 当前线程获取锁的次数1
* 第二次获取锁
* 当前线程获取锁的次数2
* 当前线程获取锁的次数1
* Thread[Thread-0,5,main]期望抢到锁
*/
说明:执行输出到这里就等待着,程序不结束,可重入锁必须加锁次数和解锁次数相同,否则其他线程拿不到锁
- ReadWriteLock
维护一堆关联锁,一个用于只读操作,一个用于写入;读锁可以由多个线程同时持有,写锁是排他的。
适合读取线程比写入线程多的场景,改进互斥锁的性能,示例:缓存组件、集合的并发线程安全性改造。
锁降级
指的是写锁降级成读锁,把持住当前拥有的写锁的同时,再获取读锁,随后释放写锁的过程。
写锁是线程独占,读锁是共享,所以写-》读是降级。(读-》写,是不能实现的)
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class CacheDemo {
private Map<String,Object> map=new HashMap<>();
private static ReadWriteLock rwl=new ReentrantReadWriteLock();
public Object get(String id) {
Object value=null;
//首先开启读锁,从缓存中去取
rwl.readLock().lock();
try{
if (map.get(id)==null) {
//必须释放读锁-读锁全部释放了,才能下面加上写锁
rwl.readLock().unlock();
//如果不加写锁,所有请求全部去查询数据库,就崩溃了
rwl.writeLock().lock();
try{
//双重检查,防止已经有线程改变了当前的只,从而出现重复处理的情况
if (map.get(id)==null) {
//如果没有缓存,就去数据库里面读取
}
rwl.readLock().lock();
//加读锁把写锁降级为读锁,这样就不会有其他线程能够修改找个值,保证了数据一致性
//因为此处加了一把读锁,只要有任何一把读锁没释放,就永远不可能有其他线程拿到写锁,也就没法修改数据
}finally {
rwl.writeLock().unlock();//释放写锁
}
}
}finally {
rwl.readLock().unlock();
}
return value;
}
public static void main(String[] args) {
}
}
-
Condition
用于替换wait/notify;Object中的wait(),notify(),notifyAll()方法是和synchronized配合使用的,可以唤醒一个或者全部(单个等待集);
Condition是需要与Lock配合使用的,提供多个等待集合,更精确的控制(底层是park/unpark机制)
6.png
class BoundedBuffer {
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
final Object[] items = new Object[100];
int putptr, takeptr, count;
public void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)
notFull.await();
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
notEmpty.signal();
} finally {
lock.unlock();
}
}
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)
notEmpty.await();
Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count;
notFull.signal();
return x;
} finally {
lock.unlock();
}
}
}
- ReentrantLock的lock和lockInterruptibly的区别
ReentrantLock的加锁方法Lock()提供了无条件地轮询获取锁的方式,lockInterruptibly()提供了可中断的锁获取方式。这两个方法的区别在哪里呢?通过分析源码可以知道lock方法默认处理了中断请求,一旦监测到中断状态,则中断当前线程;而lockInterruptibly()则直接抛出中断异常,由上层调用者区去处理中断。
- lock操作
lock获取锁过程中,忽略了中断,在成功获取锁之后,再根据中断标识处理中断,即selfInterrupt中断自己。 acquire操作源码如下:
/**
*默认处理中断方式是selfInterrupt
*/
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
acquireQueued,在for循环中无条件重试获取锁,直到成功获取锁,同时返回线程中断状态。该方法通过for循正常返回时,必定是成功获取到了锁。
/**
*无条件重试,直到成功返回,并且记录中断状态
*/
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next =null; // help GC
failed =false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted =true;
}
}finally {
if (failed)
cancelAcquire(node);
}
}
- lockInterruptibly操作
可中断加锁,即在锁获取过程中不处理中断状态,而是直接抛出中断异常,由上层调用者处理中断。源码细微差别在于锁获取这部分代码,这个方法与acquireQueue差别在于方法的返回途径有两种,一种是for循环结束,正常获取到锁;另一种是线程被唤醒后检测到中断请求,则立即抛出中断异常,该操作导致方法结束。
/**
* Acquires in exclusive interruptible mode.
* @param arg the acquire argument
*/
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next =null; // help GC
failed =false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
}finally {
if (failed)
cancelAcquire(node);
}
}
结论:ReentrantLock的中断和非中断加锁模式的区别在于:线程尝试获取锁操作失败后,在等待过程中,如果该线程被其他线程中断了,它是如何响应中断请求的。lock方法会忽略中断请求,继续获取锁直到成功;而lockInterruptibly则直接抛出中断异常来立即响应中断,由上层调用者处理中断。
那么,为什么要分为这两种模式呢?这两种加锁方式分别适用于什么场合呢?根据它们的实现语义来理解,我认为lock()适用于锁获取操作不受中断影响的情况,此时可以忽略中断请求正常执行加锁操作,因为该操作仅仅记录了中断状态(通过Thread.currentThread().interrupt()操作,只是恢复了中断状态为true,并没有对中断进行响应,也就是说继续参与锁竞争
)。如果要求被中断线程不能参与锁的竞争操作,则此时应该使用lockInterruptibly方法,一旦检测到中断请求,立即返回不再参与锁的竞争并且取消锁获取操作(即finally中的cancelAcquire操作)