我靠！Semaphore里面竟然有这么一个大坑

时间  2020-09-20
标签 我靠 semaphore 里面 竟然 有这 一个 大坑 栏目 Java 繁體版
原文   原文链接

https://mp.weixin.qq.com/s/0J1bbgCqQWqNlAzbnhI_bQ spring

image.png

荒腔走板


你们好，我是why哥 ，欢迎来到我连续周更优质原创文章的第 59 篇。编程

上周写了一篇文章，一不当心戳到了你们的爽点，其中一个转载我文章的大号，阅读量竟然突破了 10w+，我也是受宠若惊。springboot

可是其实我是一个技术博主来的，偶尔写点生活相关的。因此这篇仍是回到技术上。多线程

可是个人技术文章有个特色是第一张图片都是我本身拍的。而后我会围绕这个图片进行一个简短的描述，我称之为荒腔走板环节。并发

目的是给冰冷的技术文注入一丝色彩。app

我这样作已经坚持了不少篇 ，有的读者给我说：看完荒腔走板部分就退出去了。dom

那大家是真的棒哦，至少退出去以前，拉到文末，来个一键三连吧，给我来点正反馈。ide

好了，先说说这期的荒腔走板。高并发

上面这个图片是我上周末看《乐队的夏天》的时候拍的。测试

这个乐队的名字叫作水木年华，我喜欢这个乐队。

我听他们的歌的时候，应该是初中，那个时候磁带已经差很少快过气了，进入了光碟的时代，我记得一张光碟里面有好几十首歌，第一次在 DVD 里面听到他们的歌是《一辈子有你》，听到这首歌的时候就感受很干净，很惊艳。

而后一字一句抄在本身的歌词本上。

听到这首歌的那个周末，我就看着那个 MV 反复学，那时的 DVD 有个功能是能够 A-B 反复播放某个片断，我就一句一句的学，学会了这首歌。

那时候的李健，一双清澈明亮的大眼睛，就像一汪湖水，我一个小男孩，都好想在他的眼睛里扎个猛子。

这首歌，我愿称之为校园民谣的巅峰之一。

十多年后的今天，这个乐队从新出如今个人视野中，只是李健已经再也不其中。

他们在乐队的夏天的舞台上唱了一首《青春再见》，结果被一个自称 23 岁的胖小伙说“中年人的油腻”，被另个专业乐迷说：“四十多岁的人怎么还在唱青春再见？”。第一期就被淘汰出局。

这操做，看的我一愣一愣的。

这个怎么就油腻了？四十多岁的人怎么就不能唱青春再见了？男人至死都是少年大家不知道吗？小子，他们玩音乐的时候你还不会说话呢。

他们离开舞台的画面，我感受到一丝辛酸，一丝真的青春再见的辛酸。

水木年华没有错，错的是这个舞台，这个舞台不适合他们的歌曲。

好了，说回文章。

一块儿看个问题


前几天有个读者给我发了一个连接，说这个连接里面的代码，为何会这样运行，实在是没有搞懂是怎么回事，连接以下：

https://springboot.io/t/topic/1139

image.png

代码是这样的，给你们上个图：

image.png

注意第 10 行，permits 参数，根据他的描述应该是 3：

image.png

不知道为何代码里面给了一个 2。可是为了保证真实，我直接拿过来了，没有进行改动。一会我会根据这个代码进行简单的修改。

知道 semaphore 是干啥的同窗能够先看看上面的代码，为何形成了“死锁”。

反正是一个很是无语的低级错误，可是我反复看了几遍竟然没有看出来。

不知道 semaphore 是干啥的同窗，看过来。我先给你科普一下。

semaphore 咱们通常叫它信号量，用来控制同时访问指定资源的线程数量。

若是不懂 semaphore ，那上面代码你也看不懂了，我按照代码的逻辑给你举个例子。

好比一个高端停车场，只有 3 个车位。（这就是“指定资源”）

如今里面没有停车，那么它最多能够停几辆车呢？

是的，门口的剩余车辆指示牌显示：剩余停车位 3 辆。

这个时候，有三路人想要过来停车。

三条路分别是：转发路、点赞路、赞扬路。

image.png

路上的车分别是 why 哥的劳斯莱斯、赵四的布加迪、刘能、谢广坤这对好基友开的法拉利：

image.png

这个时候从“点赞路”过来的赵四先开到了，因而停了进去。

门口的停车位显示：剩余停车位 2 辆。

image.png

刘能、谢广坤到了后发现，恰好还剩下 2 个车位，因而好基友手拉手，一块儿停了进去。

门口的停车位显示：余下车位 0 辆。

image.png

没多久，我也到了，发现没有停车位了，怎么办呢？我只有在门口等一下了。

没一会，赵四办完事了，开着他的布加迪走了。

门口的停车位显示：余下车位 1 辆。

image.png

我赶忙停进去。

门口的停车位显示：余下车位 0 辆。

image.png

上面的代码想要描述的就是这样的一个事情。

可是根据提问者的描述，“在运行时，有时只会执行完线程A，其线程B和线程C都静默了。”

在上面这个场景中就是：赵四的布加迪开进去停车后，后面刘能、谢广坤的法拉利和个人劳斯莱斯都停不进去了。

就是这样式儿的：

image.png

为何停不进去呢？他怀疑是死锁了，这个怀疑有点无厘头啊。

咱们先回忆一下死锁的四个必要条件：

  • 互斥条件：一个资源每次只能被一个进程使用，即在一段时间内某资源仅为一个进程所占有。此时如有其余进程请求该资源，则请求进程只能等待。（不知足，还有两个停车位没有用呢。）

  • 请求与保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其余进程占有，此时请求进程被阻塞，但对本身已得到的资源保持不放。（不知足，张三占了一个停车位了，没有提出还要一个停车位的要求，另外的停车位也没有被占用）

  • 不可剥夺条件:进程所得到的资源在未使用完毕以前，不能被其余进程强行夺走，即只能由得到该资源的进程本身来释放。（知足，张三的车不开出来，这个停车位理论上是不会被夺走的）

  • 循环等待条件: 若干进程间造成首尾相接循环等待资源的关系。（不知足，只有我和刘能、谢广坤两拨人在等资源，但没有循环等待的状况。）

这四个条件是死锁的必要条件，必要条件就是说只要有死锁了，这些条件必然所有成立。

而通过分析，咱们发现没有知足死锁的必要条件。那为何会出现这样的现象呢？

咱们先根据上面的场景，本身写一段代码。

本身撸代码


下面的程序基本上是按照上面截图中的示例代码接合上面的故事改的，能够直接复制粘贴：

public class ParkDemo {
    public static void main(String[] args) throws InterruptedException {

        Integer parkSpace = 3;
        System.out.println("这里有" + parkSpace + "个停车位,先到先得啊！");
        Semaphore semaphore = new Semaphore(parkSpace, true);

        Thread threadA = new Thread(new ParkCar(1, "布加迪", semaphore), "赵四");
        Thread threadB = new Thread(new ParkCar(2, "法拉利", semaphore), "刘能、谢广坤");
        Thread threadC = new Thread(new ParkCar(1, "劳斯莱斯", semaphore), "why哥");

        threadA.start();
        threadB.start();
        threadC.start();
    }
}

class ParkCar implements Runnable {
    
    private int n;
    private String carName;
    private Semaphore semaphore;

    public ParkCar(int n, String carName, Semaphore semaphore) {
        this.n = n;
        this.carName = carName;
        this.semaphore = semaphore;
    }

    @Override
    public void run() {
        try {
            if (semaphore.availablePermits() < n) {
                System.out.println(Thread.currentThread().getName() + "来停车,可是停车位不够了,等着吧");
            }
            semaphore.acquire(n);
            System.out.println(Thread.currentThread().getName() + "把本身的" + carName + "停进来了,剩余停车位:" + semaphore.availablePermits() + "辆");
            //模拟停车时长
            int parkTime = ThreadLocalRandom.current().nextInt(1, 6);
            TimeUnit.SECONDS.sleep(parkTime);
            System.out.println(Thread.currentThread().getName() + "把本身的" + carName + "开走了,停了" + parkTime + "小时");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            semaphore.release(n);
            System.out.println(Thread.currentThread().getName() + "走后,剩余停车位:" + semaphore.availablePermits() + "辆");
        }
    }
}

运行后的结果以下（因为是多线程环境，运行结果可能不尽相同）：

image.png

此次这个运行结果和咱们预期的是一致的。并无线程阻塞的现象。

那为何以前的代码就会出现“在运行时，有时只会执行完线程A，其线程B和线程C都静默了”这种现象呢？

是道德的沦丧，仍是人性的扭曲？我带你们走进代码：

image.png

差别就体如今获取剩余通行证的方法上。上面是连接里面的代码，下面是我本身写的代码。

说实在的，连接里面的代码我最开始硬是眼神编译了一分钟，没有看出问题来。

当我真正把代码粘到 IDEA 里面，跑起来后发现当最早执行了 B 线程后，A、C 线程均可以执行。当最早执行 A 线程的时候，B、C 线程就不会执行。

我人都懵逼了，反复分析，发现这和我认知不同啊！因而我陷入了沉思：

image.png

过了一会，保洁大爷过来收垃圾，问我：“hi，小帅哥，你这瓶红牛喝完了吧？我把瓶子收走了啊。”而后瞟了一眼屏幕，指着获取剩余许可证的那行代码对我说：“你这个地方方法调用错了哈，你再好好看看方法说明。”

System.out.println("剩余可用许可证: " + semaphore.drainPermits());

说完以后，拍了拍个人肩膀，转身离去。获得大师点化，我才恍然大悟。

image.png

因为获取剩余可用许可证的方法是 drainPermits，因此线程 A 调用完成以后，剩下的许可证为0，而后执行 release 以后，许可证变为 1。（后面会有对应的方法解释）

这时又是一个公平锁，因此，若是线程 B 先进去排队了，剩下的许可证不足以让 B 线程运行，它就一直等着。C 线程也就没有机会执行。

把获取剩余可用许可证的方法换为 availablePermits 方法后，正常输出：

image.png

这真的是一个很小的点。所谓当局者迷旁观者清，就是这个道理。

image.png

方法解释


我估计不少不太了解 semaphore 的朋友看完前面这两部分也仍是略微有点懵逼。

没事，全部的疑惑将在这一小节解开。

在上面的测试案例中，咱们只用到了 semaphore 的四个方法：

  • availablePermits：获取剩余可用许可证。

  • drainPermits ：获取剩余可用许可证。

  • release（int n）：释放指定数量的许可证。

  • acquire（int n）：申请指定数量的许可证。

首先看 availablePermits 和  drainPermits 这个两个方法的差别：

image.png

这两个地方的文档描述，有点玩文字游戏的意思了。稍不留神就被带进去了。

你仔细看：availablePermits 只是 return 当前可用的许可证数量。而 drainPermits 是 acquires and return，它先所有获取后再返回。

availablePermits 只是看看还有多少量可证，drainPermits 是拿走全部剩下的许可证。

因此在上面的场景下，这两个方法的返回值是同样的，可是内部处理彻底内部不同：

image.png

当我把这个发现汇报给保洁大爷后，大爷轻轻一笑：“小伙子，要不你去查一下 drainPermits 前面的 drain 的意思？”

查完以后，我留下了英语四级的泪水：

image.png

见名知意。同窗们，可见英语对编程仍是很是重要的。

接下来先看看释放的方法：release。

image.png

该方法就是释放指定数量许可证。释放，就意味着许可证的增长。就相似于刘能、谢广坤把他们各自的法拉利从停车位开出来，驶离停车场，这时停车场就会多两个停车位。

上面红框框起来的部分是它的主要逻辑。你们本身看一下，我就不翻译了，大概意思就是释放许可证以后，其余等着用许可证的线程就能够看一下释放以后的许可证数量是否够用，若是够就能够获取许可证，而后运行了。

该方法的精华在 599 到 602 行的说明中：

image.png

这句话很是关键：说的是执行 release 操做的线程不必定非得是执行了 acquire 方法的线程。

开发人员，须要根据实际场景来保证 semaphore 的正确使用。

release 操做这里，你们都知道须要放到 finally 代码块里面去执行。可是正是这个认知，是最容易踩坑的地方，并且出了问题还很是很差排查的那种。

放确定是要放在 finally 代码块里面的，只是怎么放，这里有点讲究。

我结合下一节的例子和 acquire 方法一块儿说明：

image.png

acquire 方法主要先关注我红框框起来的部分。

从该方法的源码能够看出，会抛出 InterruptException 异常。记住这点，咱们在下一节，带入场景讨论。

release使用不当的大坑


咱们仍是带入以前停车的场景。假设赵四和我先把车停进去了，这个时候刘能、谢广坤他们来了，发现车位不够了，两个好基友嘛，就等着，非要停在一块儿：

image.png

等了一会，咱们一直没出来，门口看车的大爷出来对他们说：“我估摸着大家还得等很长时间，别等了，快走吧。”

因而，他们开车离去。

来，就这个场景，整一段代码：

public class ParkDemo {
    public static void main(String[] args) throws InterruptedException {

        Integer parkSpace = 3;
        System.out.println("这里有" + parkSpace + "个停车位,先到先得啊！");
        Semaphore semaphore = new Semaphore(parkSpace, true);

        Thread threadA = new Thread(new ParkCar(1, "布加迪", semaphore), "赵四");
        Thread threadB = new Thread(new ParkCar(2, "法拉利", semaphore), "刘能、谢广坤");
        Thread threadC = new Thread(new ParkCar(1, "劳斯莱斯", semaphore), "why哥");

        threadA.start();
        threadC.start();
        threadB.start();
        //模拟大爷劝退
        threadB.interrupt();
    }
}

class ParkCar implements Runnable {

    private int n;
    private String carName;
    private Semaphore semaphore;

    public ParkCar(int n, String carName, Semaphore semaphore) {
        this.n = n;
        this.carName = carName;
        this.semaphore = semaphore;
    }

    @Override
    public void run() {
        try {
            if (semaphore.availablePermits() < n) {
                System.out.println(Thread.currentThread().getName() + "来停车,可是停车位不够了,等着吧");
            }
            semaphore.acquire(n);
            System.out.println(Thread.currentThread().getName() + "把本身的" + carName + "停进来了," + "剩余停车位:" + semaphore.availablePermits() + "辆");
            //模拟停车时长
            int parkTime = ThreadLocalRandom.current().nextInt(1, 6);
            TimeUnit.SECONDS.sleep(parkTime);
            System.out.println(Thread.currentThread().getName() + "把本身的" + carName + "开走了,停了" + parkTime + "小时");
        } catch (InterruptedException e) {
            System.err.println(Thread.currentThread().getName() + "被门口大爷劝走了。");
        } finally {
            semaphore.release(n);
            System.out.println(Thread.currentThread().getName() + "走后,剩余停车位:" + semaphore.availablePermits() + "辆");
        }
    }
}

看着代码是没有毛病，可是运行起来你会发现，有可能出现这样的状况：

image.png

why哥走后，剩余停车位变成了 5 辆？我是开着劳斯莱斯去给他们开发停车位去了吗？

image.png

在往前看日志发现，原来是刘能、谢广坤走后，显示了剩余停车位 3 辆。

问题就出在这个地方。

而这个地方对应的代码是这样的：

image.png

有没有一点恍然大悟的感受。

50 行抛出了 InterruptedException，致使明明没有获取到许可证的线程，执行了 release 方法，而该方法致使许可证增长。

在咱们的例子里面就是刘能、谢广坤的车都还没停进去，走的时候门口的显示屏就增长了两个停车位。

这就是坑，就是你代码中的 BUG 潜伏地带。

并且还很是的危险，你想你代码里面莫名其妙的多了几个“许可证”。就意味着可能又多于你预期的线程在运行。很危险。

那么怎么修复呢？

答案已经呼之欲出了,这个地方须要 catch 起来，若是出现中断异常，直接返回：

image.png

跑起来，结果也正确，全部车都走了后，停车位仍是只有 3 辆：

image.png

上面的写法还有一个疑问，若是我刚刚拿到许可证，就被中断了，怎么办？

看源码啊，源码里面有答案的。

image.png

抛出 InterruptedException 后，分配给这个线程的全部许可证都会被分配给其余想要获取许可证的线程，就像经过调用 release 方法同样。

加强release


你分析上面的问题会发现，致使问题的缘由是没有获取到许可证的线程，调用了 release 方法。

我以为这个设定，就是很是容易踩坑的地方。简直就是一个大坑！

咱们能够就这个问题，对 release 方法进行加强，只有获取后的线程，才能调用 release 方法。

这一招我是在《Java高并发编程详解-深刻理解并发核心库》里面学到的：

image.png

其中的 3.4.4 小节《扩展 Semaphore 加强 release》:

image.png

获取许可证的方法被修改为这样了（我只截取其中一个方法），获取成功后放入到队列里面：

image.png

里面的 release 方法修改为这样了，执行以前先看看当前线程是不是在队列里面：

image.png

还有一段舒适提示：

image.png

看了有什么收获的，写下来，来我这里投稿呀。

最后说一句（求关注）


都看到这里了安排个“一键三连”（转发、在看、点赞）吧，周更很累的，不要白嫖我，须要一点正反馈。


image.png

才疏学浅，不免会有纰漏，若是你发现了错误的地方，因为本号没有留言功能，还请你在后台留言指出来，我对其加以修改。

感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

image.png

我是 why，一个被代码耽误的文学创做者，不是大佬，可是喜欢分享，是一个又暖又有料的四川好男人。

还有，重要的事情说三遍：

欢迎关注我呀。

欢迎关注我呀。

欢迎关注我呀。

image.png

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程