作者:汤圆
个人博客:javalover.cc
在前面并发的开篇,我们介绍过内置锁synchronized
;
这节我们再介绍下显式锁Lock
显式锁包括:可重入锁ReentrantLock
、读写锁ReadWriteLock
关系如下所示:
显式锁和内置锁最大的区别就是:显式锁需手动获取锁和释放锁,而内置锁不需要
关于显式锁,本节会分别介绍可它的实现类 - 可重入锁,以及它的相关类 - 读写锁
下面让我们开始吧
文章如果有问题,欢迎大家批评指正,在此谢过啦
我们先来看下它的几个方法:
public ReentrantLock()
;构造函数,默认构造非公平的锁(可插队,如果某个线程获取锁时,刚好锁被释放,那么这个线程就会立马获得锁,而不管队列里的线程是否在等待)public void lock()
:获取锁,以阻塞的方式(如果其他线程持有锁,则阻塞当前线程,直到锁被释放);public void lockInterruptibly() throws InterruptedException
:获取锁,以可被中断的方式(如果当前线程被中断,则抛出中断异常);public boolean tryLock()
: 尝试获取锁,如果锁被其他线程持有,则立马返回falsepublic boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException
:尝试获取锁,并设置一个超时时间(如果超过这个时间,还没获取到锁,则返回false)public void unlock()
: 释放锁
首先我们先看下它的构造方法,内部实现如下:
public ReentrantLock() { sync = new NonfairSync(); }
可以看到,这里创建了一个非公平锁
公平锁:如果获取锁时,被其他线程持有,则将当前线程放入等待队列
非公平锁:如果获取锁时,刚好锁被释放,那么这个线程就会立马获得锁,而不管队列里的线程是否在等待
非公平锁的好处就是,可以减少线程的挂起和唤醒开销
如果某个线程的执行任务所需时间很短,甚至比唤醒队列中的线程所消耗的时间还短,那么非公平锁的优势就很明显
我们可以假设这样一个情景:
这也是为啥默认是非公平锁的原因(一般情况下,非公平锁的性能高于公平锁) 那什么时候应该用公平锁呢?
因为这种情况下,如果线程插队获取到锁,结果任务还半天执行不完,那么队列中被唤醒的线程醒来发现锁还是被占有的,就会被再次放到队列中(此时并不会提高性能,还有可能降低) 接下来我们看下关键的部分:获取锁 获取锁有多个方法,我们用代码来看下他们之间的区别
public class ReentrantLockDemo { private Lock lock = new ReentrantLock(); private int i = 0; public void add(){ lock.lock(); try { i++; }finally { System.out.println(i); lock.unlock(); } } public static void main(String[] args) throws InterruptedException { ReentrantLockDemo demo = new ReentrantLockDemo(); ExecutorService service = Executors.newFixedThreadPool(5); for (int i = 0; i < 100; i++) { service.submit(()->{ demo.add(); }); } } } 依次输出1~100,这是因为lock()获取锁时,会以阻塞的方式来获取
public class ReentrantLockDemo { private Lock lock = new ReentrantLock(); private int i = 0; public void tryAdd(){ if(lock.tryLock()){ try { i++; }finally { System.out.println(i); lock.unlock(); } } } public static void main(String[] args) throws InterruptedException { ReentrantLockDemo demo = new ReentrantLockDemo(); ExecutorService service = Executors.newFixedThreadPool(5); for (int i = 0; i < 100; i++) { service.submit(()->{ demo.tryAdd(); }); } } } 运行发现,输出永远都少于100,是因为tryLock()如果获取锁失败,会立马返回false,而不是阻塞等待
public class ReentrantLockDemo { private Lock lock = new ReentrantLock(); private int i = 0; public void interruptAdd(){ try { lock.lockInterruptibly(); i++; } catch (InterruptedException e) { e.printStackTrace(); } finally { System.out.println(i); lock.unlock(); } } public static void main(String[] args) throws InterruptedException { ReentrantLockDemo demo = new ReentrantLockDemo(); ExecutorService service = Executors.newFixedThreadPool(5); for (int i = 0; i < 100; i++) { // 第10次,立马关闭线程池,停止所有的线程(包括正在执行的和正在等待的) if (10 == i){ service.shutdownNow(); } service.submit(()->{ demo.interruptAdd(); }); } } } 多运行几次,有可能输出如下: 1 2 3 4 5 6 6 6 6 6 java.lang.InterruptedException at ...... 这就是因为前面几个都是正常获取到锁并执行了i++,但是后面的几个线程因为被突然停止,所以抛出中断异常
这个就很简单了,上面的代码都有涉及到这个释放锁 不过细心的朋友可能发现了,上面的unlock()都是在finally块中编写的 这是因为在获取锁并执行任务时,有可能抛出异常,此时如果不把unlock()放到finally块中,那么锁不被释放,这在后期是一个很大的隐患(其他线程无法再次获取到这个锁,如果是lock()形式的获取锁,则线程会一直阻塞) 这也是显式锁无法完全替代内置锁的一个原因,有危险 2. 读写锁 ReadWriteLock 读写锁内部就两个方法,分别返回读锁和写锁 读锁属于共享锁,而写锁属于独占锁(前面介绍的可重入锁和内置锁也是独占锁) 读锁允许多个线程同时获取一个锁,因为读不会修改数据,它很适合读多写少的场合 下面我们用代码来看下 先看下读锁,代码如下: public class ReadWriteLockDemo { private int i = 0; private Lock readLock; private Lock writeLock; public ReadWriteLockDemo() { ReadWriteLock lock = new ReentrantReadWriteLock(); this.readLock = lock.readLock(); this.writeLock = lock.writeLock(); } public void readFun(){ readLock.lock(); System.out.println("=== 获取到 读锁 ==="); try { System.out.println(i); }finally { readLock.unlock(); System.out.println("=== 释放了 读锁 ==="); } } public static void main(String[] args) throws InterruptedException { ReadWriteLockDemo demo = new ReadWriteLockDemo(); ExecutorService executors = Executors.newFixedThreadPool(2); for (int i = 0; i < 10; i++) { executors.submit(()->{ demo.readFun(); }); } } } 多次运行,有可能输出下面的结果: === 获取到 读锁 === 0 === 获取到 读锁 === 可以看到,两个线程都获取到了读锁,这就是读锁的优势,多个线程同时读 下面看下写锁,代码如下:(这里用到了ReentrantReadWriteLock类,表示可重入的读写锁) public class ReadWriteLockDemo { private int i = 0; private Lock readLock; private Lock writeLock; public ReadWriteLockDemo() { ReadWriteLock lock = new ReentrantReadWriteLock(); this.readLock = lock.readLock(); this.writeLock = lock.writeLock(); } public void writeFun(){ writeLock.lock(); System.out.println("=== 获取到 写锁 ==="); try { i++; System.out.println(i); }finally { writeLock.unlock(); System.out.println("=== 释放了 写锁 ==="); } } public static void main(String[] args) throws InterruptedException { ReadWriteLockDemo demo = new ReadWriteLockDemo(); ExecutorService executors = Executors.newFixedThreadPool(2); for (int i = 0; i < 10; i++) { executors.submit(()->{ demo.writeFun(); }); } } } 输出如下:可以看到,写锁类似上面的重入锁的lock()方法,阻塞获取写锁 === 获取到 写锁 === 1 === 释放了 写锁 === === 获取到 写锁 === 2 === 释放了 写锁 === === 获取到 写锁 === 3 === 释放了 写锁 === === 获取到 写锁 === 4 === 释放了 写锁 === === 获取到 写锁 === 5 === 释放了 写锁 === === 获取到 写锁 === 6 === 释放了 写锁 === === 获取到 写锁 === 7 === 释放了 写锁 === === 获取到 写锁 === 8 === 释放了 写锁 === === 获取到 写锁 === 9 === 释放了 写锁 === === 获取到 写锁 === 10 === 释放了 写锁 === 关于读写锁,需要注意的一点是,读锁和写锁必须基于同一个ReadWriteLock类才有意义 如果读锁和写锁分别是从两个ReadWrite Lock类中获取的,那么读锁和写锁就是完全无关的两个锁,也就不会起到锁的作用(阻止其他线程访问) 这就类似synchronized(a)和synchronized(b),分别锁了两个对象,此时单个线程是可以同时访问这两个锁的 3. 区别 我们用表格来展示吧,细节如下: 锁的特点内置锁可重入锁读写锁灵活性低高高公平性不确定非公平(默认)+公平非公平(默认)+公平定时性无可定时可定时中断性无可中断可中断互斥性互斥互斥读读共享,其他都互斥建议优先选择内置锁,只有在内置锁满足不了需求时,再采用显式锁(比如可定时、可中断、公平性) 如果是读多写少的场景(比如配置数据),推荐用读写锁 总结
建议使用锁时,优先考虑内置锁 因为现在内置锁的性能跟显式锁差别不大 而且显式锁因为需要手动释放锁(需在finally块中释放),所以会有忘记释放的风险 如果是读多写少的场合,则推荐用读写锁(成对的读锁和写锁需从同一个读写锁类获取) 参考内容:
后记 最后,祝愿所有人都心想事成,阖家欢乐
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。