Java中提供了synchronized,为什么还要提供Lock呢?

开发 后端
在Java中提供了synchronized关键字来保证只有一个线程能够访问同步代码块。既然已经提供了synchronized关键字,那为何在Java的SDK包中,还会提供Lock接口呢?这是不是重复造轮子,多此一举呢?今天,我们就一起来探讨下这个问题。

 [[342267]]

作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址:

https://github.com/sunshinelyz/mykit-delay

写在前面

在Java中提供了synchronized关键字来保证只有一个线程能够访问同步代码块。既然已经提供了synchronized关键字,那为何在Java的SDK包中,还会提供Lock接口呢?这是不是重复造轮子,多此一举呢?今天,我们就一起来探讨下这个问题。

再造轮子?

既然JVM中提供了synchronized关键字来保证只有一个线程能够访问同步代码块,为何还要提供Lock接口呢?这是在重复造轮子吗?Java的设计者们为何要这样做呢?让我们一起带着疑问往下看。

为何提供Lock接口?

很多小伙伴可能会听说过,在Java 1.5版本中,synchronized的性能不如Lock,但在Java 1.6版本之后,synchronized做了很多优化,性能提升了不少。那既然synchronized关键字的性能已经提升了,那为何还要使用Lock呢?

如果我们向更深层次思考的话,就不难想到了:我们使用synchronized加锁是无法主动释放锁的,这就会涉及到死锁的问题。

死锁问题

如果要发生死锁,则必须存在以下四个必要条件,四者缺一不可。

 

互斥条件

在一段时间内某资源仅为一个线程所占有。此时若有其他线程请求该资源,则请求线程只能等待。

不可剥夺条件

线程所获得的资源在未使用完毕之前,不能被其他线程强行夺走,即只能由获得该资源的线程自己来释放(只能是主动释放)。

请求与保持条件

线程已经保持了至少一个资源,但又提出了新的资源请求,而该资源已被其他线程占有,此时请求线程被阻塞,但对自己已获得的资源保持不放。

循环等待条件

在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源,P2等待P3占有的资源,…,pn等待p1占有的资源,形成一个进程等待环路,环路中每一个进程所占有的资源同时被另一个申请,也就是前一个进程占有后一个进程所深情地资源。

synchronized的局限性

如果我们的程序使用synchronized关键字发生了死锁时,synchronized关键是是无法破坏“不可剥夺”这个死锁的条件的。这是因为synchronized申请资源的时候, 如果申请不到, 线程直接进入阻塞状态了, 而线程进入阻塞状态, 啥都干不了, 也释放不了线程已经占有的资源。

然而,在大部分场景下,我们都是希望“不可剥夺”这个条件能够被破坏。也就是说对于“不可剥夺”这个条件,占用部分资源的线程进一步申请其他资源时, 如果申请不到, 可以主动释放它占有的资源, 这样不可剥夺这个条件就破坏掉了。

如果我们自己重新设计锁来解决synchronized的问题,我们该如何设计呢?

解决问题

了解了synchronized的局限性之后,如果是让我们自己实现一把同步锁,我们该如何设计呢?也就是说,我们在设计锁的时候,要如何解决synchronized的局限性问题呢?这里,我觉得可以从三个方面来思考这个问题。

(1)能够响应中断。synchronized的问题是, 持有锁A后, 如果尝试获取锁B失败, 那么线程就进入阻塞状态, 一旦发生死锁, 就没有任何机会来唤醒阻塞的线程。但如果阻塞状态的线程能够响应中断信号, 也就是说当我们给阻塞的线程发送中断信号的时候, 能够唤醒它, 那它就有机会释放曾经持有的锁A。这样就破坏了不可剥夺条件了。

(2)支持超时。如果线程在一段时间之内没有获取到锁, 不是进入阻塞状态, 而是返回一个错误, 那这个线程也有机会释放曾经持有的锁。这样也能破坏不可剥夺条件。

(3)非阻塞地获取锁。如果尝试获取锁失败, 并不进入阻塞状态, 而是直接返回, 那这个线程也有机会释放曾经持有的锁。这样也能破坏不可剥夺条件。

体现在Lock接口上,就是Lock接口提供的三个方法,如下所示。

  1. // 支持中断的API 
  2. void lockInterruptibly() throws InterruptedException; 
  3. // 支持超时的API 
  4. boolean tryLock(long time, TimeUnit unit) throws InterruptedException; 
  5. // 支持非阻塞获取锁的API 
  6. boolean tryLock(); 

lockInterruptibly()

支持中断。

tryLock()方k

tryLock()方法是有返回值的,它表示用来尝试获取锁,如果获取成功,则返回true,如果获取失败(即锁已被其他线程获取),则返回false,也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

tryLock(long time, TimeUnit unit)方法

tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的,只不过区别在于这个方法在拿不到锁时会等待一定的时间,在时间期限之内如果还拿不到锁,就返回false。如果一开始拿到锁或者在等待期间内拿到了锁,则返回true。

也就是说,对于死锁问题,Lock能够破坏不可剥夺的条件,例如,我们下面的程序代码就破坏了死锁的不可剥夺的条件。

  1. public class TansferAccount{ 
  2.     private Lock thisLock = new ReentrantLock(); 
  3.     private Lock targetLock = new ReentrantLock(); 
  4.     //账户的余额 
  5.     private Integer balance; 
  6.     //转账操作 
  7.     public void transfer(TansferAccount target, Integer transferMoney){ 
  8.         boolean isThisLock = thisLock.tryLock(); 
  9.         if(isThisLock){ 
  10.             try{ 
  11.                 boolean isTargetLock = targetLock.tryLock(); 
  12.                 if(isTargetLock){ 
  13.                     try{ 
  14.                          if(this.balance >= transferMoney){ 
  15.                             this.balance -= transferMoney; 
  16.                             target.balance += transferMoney; 
  17.                         }    
  18.                     }finally{ 
  19.                         targetLock.unlock 
  20.                     } 
  21.                 } 
  22.             }finally{ 
  23.                 thisLock.unlock(); 
  24.             } 
  25.         } 
  26.     } 

例外,Lock下面有一个ReentrantLock,而ReentrantLock支持公平锁和非公平锁。

在使用ReentrantLock的时候, ReentrantLock中有两个构造函数, 一个是无参构造函数, 一个是传入fair参数的构造函数。fair参数代表的是锁的公平策略, 如果传入true就表示需要构造一个公平锁, 反之则表示要构造一个非公平锁。如下代码片段所示。

  1. //无参构造函数: 默认非公平锁 
  2. public ReentrantLock() { 
  3.  sync = new NonfairSync(); 
  4. }  
  5. //根据公平策略参数创建锁 
  6. public ReentrantLock(boolean fair){ 
  7.  sync = fair ? new FairSync() : new NonfairSync(); 

锁的实现在本质上都对应着一个入口等待队列, 如果一个线程没有获得锁, 就会进入等待队列, 当有线程释放锁的时候, 就需要从等待队列中唤醒一个等待的线程。如果是公平锁, 唤醒的策略就是谁等待的时间长, 就唤醒谁, 很公平;如果是非公平锁, 则不提供这个公平保证, 有可能等待时间短的线程反而先被唤醒。 而Lock是支持公平锁的,synchronized不支持公平锁。

最后,值得注意的是,在使用Lock加锁时,一定要在finally{}代码块中释放锁,例如,下面的代码片段所示。

  1. try{ 
  2.     lock.lock(); 
  3. }finally{ 
  4.     lock.unlock(); 

注:其他synchronized和Lock的详细说明,小伙伴们自行查阅即可。

本文转载自微信公众号「 冰河技术」,可以通过以下二维码关注。转载本文请联系 冰河技术公众号。

 

责任编辑:武晓燕 来源: 冰河技术
相关推荐

2009-07-14 14:50:00

JOptionPane

2022-09-29 15:39:10

服务器NettyReactor

2022-06-07 08:39:35

RPCHTTP

2020-11-25 09:36:17

HTTPRPC远程

2019-08-05 14:23:43

DockerKubernetes容器

2023-12-11 12:03:14

Python工具元组

2020-12-15 06:57:24

java服务器

2023-01-12 09:01:01

MongoDBMySQL

2015-10-27 09:45:41

2014-07-14 15:44:05

虚拟化云计算

2019-11-20 10:39:35

iPhone缓存清理

2021-03-02 22:10:10

Java互联网语言

2021-04-16 23:28:11

Java语言IT

2015-09-01 09:28:55

calayeruiview区别

2022-09-13 08:44:02

IP网络MAC地址

2021-12-20 10:30:33

forforEach前端

2013-10-30 10:47:32

2024-02-21 11:19:02

AI人工智能GenAI

2022-07-12 08:56:18

公平锁非公平锁Java

2024-03-08 07:53:19

LockMonitor线程
点赞
收藏

51CTO技术栈公众号