java并发高频面试题:Sempahore的使用场景与常见误区

雨点打透心脏的1/2处 2022-09-11 13:20 107阅读 0赞

做积极的人，越努力越幸运！

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

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

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

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

## 1、Sempahore使用场景 ##

--------------------

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

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

候选人：多线程jdk提供了丰富的工具，都集中在JUC包中，通常有线程池、Semaphore、CountDownLatch、原子类等。

面试官：那你能说说信号量Semaphore通常在什么场景下使用呢？

候选人：限流

面试官：如何基于Semaphore进行限流？

候选人：。。。。。。

面试官：看图说话，这段代码是否正确？

![86ab814910bed92af03808602ca4716f.png][]  
**Sempahore信号量最经典的使用场景是限流，用于控制并发度。**

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

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

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

该如何处理呢？**Sempahore闪亮登场，可通过发放一定数量的许可从而控制并发度**。

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

--------------------

Sempahore的使用场景非常经典，其使用看上去非常简单，其基本的使用代码如下：

![79cc13687fd893c58e900d6d77174f73.png][]  
上面的方法就是控制doSomeThing()方法的调用并发度，即同一时间允许多少个线程并发执行doSomeThing()方法中的代码，简单说明一下：

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

> 温馨提示：上面的代码有漏洞，你能发现吗？

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

![6eadd79d2bd86a9149403c9ac9921afe.png][]

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

--------------------

上面只是“小试牛刀”，使用Sempahore真正的挑战在于多线程环境中，我们回到开头部分的场景，调用第三方接口解析图片，并使用多线程提高并发度，示例代码如下：

![2192d92b4259e1d954aae3e0471339ab.png][]  
该示例主要是结合CompletableFuture实现多线程并发，并结合信号量控制调用第三方接口的并发度(这里用doSomeThing()方法表示)。

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

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

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

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

初步解决思路就是在cdh.awiat方法结束后判断是否超时，如果超时，手动释放许可，例如下图所示：

![59b1f62d92f97f756b243e79acb3cb35.png][]  
这样的想法好是好，但这样会造成许可的多次释放，最终导致许可数量增加，超过预期。

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

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

解决方案如下：

![886e8964faf5d3990112cf03da17841f.png][]  
引入一个包装类，包装Sempahore，并结合AtomicBoolean，保证每一个SempahoreReleaseOnlyOne对象只会释放Sempahore一次。

引入该类后，上面的代码改造如下：

![48f9a456532429c799fa29a41820e126.png][]  
本文就介绍到这里了，Semaphore看似简单，但要用好用正确还是有难度的，不知各位是否Get到了。

推荐阅读

*  [离职后，10天面试 4 家公司的总结][10_4]  
    
 *  [一套Spring Cloud Alibaba视频教程][Spring Cloud Alibaba]  
    
 *  [后端开发人员，学习之路][Link 1]
 *  [后端面试总结 23万，500多页（含答案）！][23_500]
 *  [112期面试汇总，建议收藏][112]

[86ab814910bed92af03808602ca4716f.png]: /images/20220828/1e1fa4be1c2746f095f21d6c02500559.png
[79cc13687fd893c58e900d6d77174f73.png]: /images/20220828/ae949e7a2f0c4898ae63f566b1d3c6f5.png
[6eadd79d2bd86a9149403c9ac9921afe.png]: /images/20220828/fa08d88e7d864a748feb58ae93d02b07.png
[2192d92b4259e1d954aae3e0471339ab.png]: /images/20220828/6f17bb66e48644df948bbdd5795b119e.png
[59b1f62d92f97f756b243e79acb3cb35.png]: /images/20220828/4147dfcc77d1478db1cacecd6f6bf9f8.png
[886e8964faf5d3990112cf03da17841f.png]: /images/20220828/60be919bfa3b41c58df1b347d868abf6.png
[48f9a456532429c799fa29a41820e126.png]: /images/20220828/9c213726aff444c98b48dbfc29aa3508.png
[10_4]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA==&mid=2247503026&idx=1&sn=183d38a1172e3eb4d31f60783c477c38&chksm=fd556459ca22ed4faf44bc01dbab47030bae7995cb0bcaa91b55a9e130b2a9e0be119dea29ef&scene=21#wechat_redirect
[Spring Cloud Alibaba]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA==&mid=2247502542&idx=2&sn=efbdc5883e72041b423df9dd229723f1&chksm=fd556225ca22eb33a3859702053e4f6817f646264cf58fabe5c9f18144da347305a2a6d8b0e6&scene=21#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA==&mid=2247499704&idx=1&sn=e3a867f360e8a8cccf8d79e0652c36c0&chksm=fd555753ca22de4522b62563737854b0359847f046b416df20cdfa099ea81d8e03c8bb22f4d1&scene=21#wechat_redirect
[23_500]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA==&mid=2247503326&idx=1&sn=a35bd6b6dd62d742f34c7c80e8f8f421&chksm=fd556535ca22ec2350b399f33fd1125ce75dd34f1351b47cb70c2a60ffad803853209fd083b4&scene=21#wechat_redirect
[112]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA==&mid=2247503308&idx=2&sn=0464ed003b29d85ae47f5b330cade32e&chksm=fd556527ca22ec310441fb12453e0bd624fb0e4bfa18919d1141d3641b9c462a9a28113dc95a&scene=21#wechat_redirect