面试官:讲讲高并发场景下如何优化加锁方式?

开发 架构
很多时候,我们在并发编程中,涉及到加锁操作时,对代码块的加锁操作真的合理吗?还有没有需要优化的地方呢?

 [[346345]]

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

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

写在前面

很多时候,我们在并发编程中,涉及到加锁操作时,对代码块的加锁操作真的合理吗?还有没有需要优化的地方呢?

问题阐述

在《【高并发】优化加锁方式时竟然死锁了!!》一文中,我们介绍了产生死锁时的四个必要条件,只有四个条件同时具备时才能发生死锁。其中,我们在阻止请求与保持条件时,采用了一次性申请所有的资源的方式。例如在我们完成转账操作的过程中,我们一次性申请账户A和账户B,两个账户都申请成功后,再执行转账的操作。其中,在我们实现的转账方法中,使用了死循环来循环获取资源,直到同时获取到账户A和账户B为止,核心代码如下所示。

  1. //一次申请转出账户和转入账户,直到成功 
  2. while(!requester.applyResources(this, target)){ 
  3.     //循环体为空 
  4.     ; 

如果ResourcesRequester类的applyResources()方法执行的时间非常短,并且程序并发带来的冲突不大,程序循环几次到几十次就可以同时获取到转出账户和转入账户,这种方案就是可行的。

但是,如果ResourcesRequester类的applyResources()方法执行的时间比较长,或者说,程序并发带来的冲突比较大,此时,可能需要循环成千上万次才能同时获取到转出账户和转入账户。这样就太消耗CPU资源了,此时,这种方案就是不可行的了。

那么,有没有什么方式对这种方案进行优化呢?

问题分析

既然使用死循环一直获取资源这种方案存在问题,那我们换位思考一下。当线程执行时,发现条件不满足,是不是可以让线程进入等待状态?当条件满足的时候,通知等待的线程重新执行?

也就是说,如果线程需要的条件不满足,我们就让线程进入等待状态;如果线程需要的条件满足时,我们再通知等待的线程重新执行。这样,就能够避免程序进行循环等待进而消耗CPU的问题。

那么,问题又来了!当条件不满足时,如何实现让线程等待?当条件满足时,又如何唤醒线程呢?

不错,这是个问题!不过这个问题解决起来也非常简单。简单的说,就是使用线程的等待与通知机制。

线程的等待与通知机制

我们可以使用线程的等待与通知机制来优化阻止请求与保持条件时,循环获取账户资源的问题。具体的等待与通知机制如下所示。

执行的线程首先获取互斥锁,如果线程继续执行时,需要的条件不满足,则释放互斥锁,并进入等待状态;当线程继续执行需要的条件满足时,就通知等待的线程,重新获取互斥锁。

那么,说了这么多,Java支持这种线程的等待与通知机制吗?其实,这个问题问的就有点废话了,Java这么优秀(牛逼)的语言肯定支持啊,而且实现起来也比较简单。

Java实现线程的等待与通知机制

实现方式

其实,使用Java语言实现线程的等待与通知机制有多种方式,这里我就简单的列举一种方式,其他的方式大家可以自行思考和实现,有不懂的地方也可以问我!

在Java语言中,实现线程的等待与通知机制,一种简单的方式就是使用synchronized并结合wait()、notify()和notifyAll()方法来实现。

实现原理

我们使用synchronized加锁时,只允许一个线程进入synchronized保护的代码块,也就是临界区。如果一个线程进入了临界区,则其他的线程会进入阻塞队列里等待,这个阻塞队列和synchronized互斥锁是一对一的关系,也就是说,一把互斥锁对应着一个独立的阻塞队列。

在并发编程中,如果一个线程获得了synchronized互斥锁,但是不满足继续向下执行的条件,则需要进入等待状态。此时,可以使用Java中的wait()方法来实现。当调用wait()方法后,当前线程就会被阻塞,并且会进入一个等待队列中进行等待,这个由于调用wait()方法而进入的等待队列也是互斥锁的等待队列。而且,线程在进入等待队列的同时,会释放自身获得的互斥锁,这样,其他线程就有机会获得互斥锁,进而进入临界区了。整个过程可以表示成下图所示。

当线程执行的条件满足时,可以使用Java提供的notify()和notifyAll()方法来通知互斥锁等待队列中的线程,我们可以使用下图来简单的表示这个过程。

这里,需要注意如下事项:

(1)使用notify()和notifyAll()方法通知线程时,调用notify()和notifyAll()方法时,满足线程的执行条件,但是当线程真正执行的时候,条件可能已经不再满足了,可能有其他线程已经进入临界区执行。

(2)被通知的线程继续执行时,需要先获取互斥锁,因为在调用wait()方法等待时已经释放了互斥锁。

(3)wait()、notify()和notifyAll()方法操作的队列是互斥锁的等待队列,如果synchronized锁定的是this对象,则一定要使用this.wait()、this.notify()和this.notifyAll()方法;如果synchronized锁定的是target对象,则一定要使用target.wait()、target.notify()和target.notifyAll()方法。

(4)wait()、notify()和notifyAll()方法调用的前提是已经获取了相应的互斥锁,也就是说,wait()、notify()和notifyAll()方法都是在synchronized方法中或代码块中调用的。如果在synchronized方法外或代码块外调用了三个方法,或者锁定的对象是this,使用target对象调用三个方法的话,JVM会抛出java.lang.IllegalMonitorStateException异常。

具体实现

实现逻辑

在实现之前,我们还需要考虑以下几个问题:

  • 选择哪个互斥锁

在之前的程序中,我们在TansferAccount类中,存在一个ResourcesRequester 类的单例对象,所以,我们是可以使用this作为互斥锁的。这一点大家需要重点理解。

  • 线程执行转账操作的条件

转出账户和转入账户都没有被分配过。

  • 线程什么时候进入等待状态

线程继续执行需要的条件不满足的时候,进入等待状态。

  • 什么时候通知等待的线程执行

当存在线程释放账户的资源时,通知等待的线程继续执行。

综上,我们可以得出以下核心代码。

  1. while(不满足条件){ 
  2.     wait(); 

那么,问题来了!为何是在while循环中调用wait()方法呢?因为当wait()方法返回时,有可能线程执行的条件已经改变,也就是说,之前条件是满足的,但是现在已经不满足了,所以要重新检验条件是否满足。

实现代码

我们优化后的ResourcesRequester类的代码如下所示。

  1. public class ResourcesRequester{ 
  2.     //存放申请资源的集合 
  3.     private List<Object> resources = new ArrayList<Object>(); 
  4.     //一次申请所有的资源 
  5.     public synchronized void applyResources(Object source, Object target){ 
  6.         while(resources.contains(source) || resources.contains(target)){ 
  7.             try{ 
  8.                 wait(); 
  9.             }catch(Exception e){ 
  10.                 e.printStackTrace(); 
  11.             } 
  12.         } 
  13.         resources.add(source); 
  14.         resources.add(targer); 
  15.     } 
  16.      
  17.     //释放资源 
  18.     public synchronized void releaseResources(Object source, Object target){ 
  19.         resources.remove(source); 
  20.         resources.remove(target); 
  21.         notifyAll(); 
  22.     } 

生成ResourcesRequester单例对象的Holder类ResourcesRequesterHolder的代码如下所示。

  1. public class ResourcesRequesterHolder{ 
  2.     private ResourcesRequesterHolder(){} 
  3.      
  4.     public static ResourcesRequester getInstance(){ 
  5.         return Singleton.INSTANCE.getInstance(); 
  6.     } 
  7.     private enum Singleton{ 
  8.         INSTANCE; 
  9.         private ResourcesRequester singleton; 
  10.         Singleton(){ 
  11.             singleton = new ResourcesRequester(); 
  12.         } 
  13.         public ResourcesRequester getInstance(){ 
  14.             return singleton; 
  15.         } 
  16.     } 

执行转账操作的类的代码如下所示。

  1. public class TansferAccount{ 
  2.     //账户的余额 
  3.     private Integer balance; 
  4.     //ResourcesRequester类的单例对象 
  5.     private ResourcesRequester requester; 
  6.     
  7.     public TansferAccount(Integer balance){ 
  8.         this.balance = balance; 
  9.         this.requester = ResourcesRequesterHolder.getInstance(); 
  10.     } 
  11.     //转账操作 
  12.     public void transfer(TansferAccount target, Integer transferMoney){ 
  13.         //一次申请转出账户和转入账户,直到成功 
  14.         requester.applyResources(this, target)) 
  15.         try{ 
  16.             //对转出账户加锁 
  17.             synchronized(this){ 
  18.                 //对转入账户加锁 
  19.                 synchronized(target){ 
  20.                     if(this.balance >= transferMoney){ 
  21.                         this.balance -= transferMoney; 
  22.                         target.balance += transferMoney; 
  23.                     }    
  24.                 } 
  25.             } 
  26.         }finally{ 
  27.             //最后释放账户资源 
  28.             requester.releaseResources(this, target); 
  29.         } 
  30.     } 

可以看到,我们在程序中通知处于等待状态的线程时,使用的是notifyAll()方法而不是notify()方法。那notify()方法和notifyAll()方法两者有什么区别呢?

notify()和notifyAll()的区别

  • notify()方法

随机通知等待队列中的一个线程。

  • notifyAll()方法

通知等待队列中的所有线程。

在实际工作过程中,如果没有特殊的要求,尽量使用notifyAll()方法。因为使用notify()方法是有风险的,可能会导致某些线程永久不会被通知到!

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

 

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

2022-04-29 08:17:38

RPC远程代理代理模式

2020-11-06 07:11:40

内存虚拟Redis

2020-09-07 06:28:37

Nginx静态负载均衡动态负载均衡

2024-02-28 10:14:47

Redis数据硬盘

2020-07-28 00:58:20

IP地址子网TCP

2021-01-13 05:27:02

服务器性能高并发

2020-09-14 06:57:30

缓存穿透雪崩

2024-09-29 00:00:00

高并发交易所宕机

2023-07-13 08:19:30

HaspMapRedis元素

2021-08-02 17:21:08

设计模式订阅

2023-03-08 07:46:53

面试官优化结构体

2021-04-26 09:05:55

高并发索引MySQL

2020-11-02 07:02:10

加载链接初始化

2015-08-13 10:29:12

面试面试官

2019-06-06 10:55:02

JDK高并发框架

2024-03-07 17:21:12

HotSpotJVMHot Code

2023-02-16 08:10:40

死锁线程

2024-09-18 09:02:14

单核服务器线程切换

2021-05-14 08:34:32

UDP TCP场景

2021-05-19 08:17:35

秒杀场景高并发
点赞
收藏

51CTO技术栈公众号