《重学Java高并发》Sempahore的使用场景与常见误区

大家好,我是威哥,《RocketMQ技术内幕》一书作者,荣获RocketMQ官方社区优秀布道师、CSDN2020博客执之星Top2等荣誉称号。目前担任中通快递技术平台部资深架构师,主要负责全链路压测、消息中间件、数据同步等产品的研发与落地,拥有千亿级消息集群的运维经验,不仅实践经验丰富,而且对其源代码有深入且系统的研究。欢迎大家关注我,一起抱团发展。

JUC,java并发框架也是面试中的常客,而Semaphore信号量又是JUC的重头戏。

Semaphore简单吗?使用起来非常简单,但最近生产环境遇到一个故障,最终原因竟然是Semaphore在多线程异步环境使用不当造成的?

读者朋友们一定会觉得很诧异,容我慢慢道来。

文章开头时先吹一个牛:我有一双“火眼金睛”,任你刷多少题,是否用过Semaphore,我一问便知。

1、Sempahore使用场景

读者朋友们对下面的对话我想肯定不会陌生:

面试官:看你简历中写到你熟悉多线程编程,那你的多线程工具包有哪些工具?

候选人:多线程jdk提供了丰富的工具,都集中在JUC包中,通常有线程池、Semaphore、CountDownLatch、原子类等。
面试官:那你能说说信号量Semaphore通常在什么场景下使用呢?
候选人:限流
面试官:如何基于Semaphore进行限流?
候选人:。。。。。。
面试官:看图说话,这段代码是否正确?
在这里插入图片描述
Sempahore信号量最经典的使用场景是限流,用于控制并发度。

回想我们在开发系统时免不了要对接第三方系统,例如在快递行业的用户端系统(寄件)时,用户通过微信小程序进行下单时,需要手动填写收件人、寄件人信息等信息,十分繁琐与低效,能否从产品角度加以改善?

当然可以,产品提成上传一张包含收件地址等信息等图片,通过AI等技术识别图片,自动提取图片中的有效信息并自动填充,提高用户体验。

通过技术选型,我们敲定了百度的免费(付费)图片识别接口,但第三方提供的配额是有限的,特别是会限制接口的并发度,超过并发度的接口将会返回错误,特别是免费类的接口更加如此?

该如何处理呢?Sempahore闪亮登场

2、许可超额现象及解决方案

Sempahore的使用场景非常经典,其使用看上区非常简单,其基本的使用代码如下:
在这里插入图片描述
上面的方法就是控制doSomeThing()方法的调用并发度,即同一时间允许多少个线程并发执行doSomeThing()方法中的代码,简单说明一下:

  • 在创建Sempahore对象时指定该信号量中包含的许可数量。
  • 在执行业务方法之前,首先向信号量对象中申请一个许可,如果申请到,acquire()方法立即返回,执行完成业务逻辑放一定要调用release()方法,释放许可。
  • 如果当前许可已全部申请,其他线程调用信号量的acquire()方法时会阻塞,当然acquire方法也可以设置超时时间,该方法的返回结果表示是否申请到许可。

温馨提示:上面的代码有漏洞,你能发现吗?

上面的代码有可能造成多释放,当10个线程分别去获取许可,都能成功,但都在执行doSomeThing()方法的时候,第11个线程尝试获取许可,但可能发生中断等异常导致没成功获取许可而触发异常,但最终进入到finally语句块,进行释放许可,这样就会增加许可数量,导致逻辑异常,这样的问题特别是在调用带超时时间的acquire方法时更加明显,其正确的使用如下图所示:
在这里插入图片描述

3、许可不释放导致无限阻塞

上面只是“小试牛刀”,使用Sempahore真正的挑战在于多线程环境中,我们回到开头部分的场景,调用第三方接口解析图片,并使用多线程提高并发度,示例代码如下:
在这里插入图片描述
该示例主要是结合CompletableFuture实现多线程并发,并结合信号量控制调用第三方接口的并发度(这里用doSomeThing()方法表示)。

温馨提示:CompleteableFuture的whenComplete事件回调函数是发生异常时也会进入,并且第二个参数为异常对象。

在JDK8中CompletableFuture暂不支持设置超时时间,故本例使用了CountDownLatch用来控制test02方法的超时时间。

上面的示例是不是非常给力,但如果细看,可能存在许可不及时释放的问题,也就示说semaphore的release()方法不会执行,因为上述方法会超时。

许可不释放带来的后果非常严重,因为后续申请的时候由于一直没有许可,将无法获取许可,而无法执行业务逻辑。

初步解决思路就是在cdh.awiat方法结束后判断是否超时,如果超时,手动释放许可,例如下图所示:
在这里插入图片描述
这样的想法好是好,但这样会造成许可的多次释放,最终导致许可数量增加,超过预期。

这其实是要求seaphore的release方法会在不同条件下在不同地方会被调用,但同一个请求只在其中一个地方被执行。

要解决这个问题,我想大家会自然而然的想到JUC中的另外的工具:原子类,尽管多次调用,我们只需第一次调用时真正释放许可,其他调用则直接忽略即可。

解决方案如下:
在这里插入图片描述
引入一个包装类,包装Sempahore,并结合AtomicBoolean,保证每一个SempahoreReleaseOnlyOne对象只会释放Sempahore一次。

引入该类后,上面的代码改造如下:
在这里插入图片描述
本文就介绍到这里了,Semaphore看似简单,但要用好用对还是有难度的,不知各位是否Get到了。如果需要整套源码,可以发送私信:SCODE,即可获取。

一键三连(关注、点赞、留言)是对我最大的鼓励

掌握一到两门java主流中间件,是敲开BAT等大厂必备的技能,送给大家一个Java中间件学习路线,助力大家早日进入互联网大厂。

Java进阶之梯,成长路线与学习资料,助力突破中间件领域

最后分享笔者一个硬核的RocketMQ电子书,您将获得千亿级消息流转的运维经验。
在这里插入图片描述
获取方式:RocketMQ电子书

文章首发:https://www.codingw.net/posts/fa8c5e0b.html

posted @ 2021-11-28 22:00  中间件兴趣圈  阅读(554)  评论(0编辑  收藏  举报