BlockingQueue 阻塞队列实现异步事件

转载请注明出处：https://www.cnblogs.com/wenjunwei/p/10411444.html

前言

本文通过一个简单的例子，来展现如何使用阻塞队列(BlockingQueue)来实现异步通信功能。(这是笔者在做日志记录时，用来做异步操作的)

BlockingQueue的核心方法

放入数据：

• offer(anObject):表示如果可能的话,将anObject加到BlockingQueue里,即如果BlockingQueue可以容纳,则返回true,否则返回false.（本方法不阻塞当前执行方法的线程）。
• offer(E o, long timeout, TimeUnit unit):可以设定等待的时间，如果在指定的时间内，还不能往队列中加入BlockingQueue，则返回失败。
• put(anObject):把anObject加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断直到BlockingQueue里面有空间再继续。

获取数据：

• poll(time):取走BlockingQueue里排在首位的对象,若不能立即取出,则可以等time参数规定的时间,取不到时返回null。
• poll(long timeout, TimeUnit unit)：从BlockingQueue取出一个队首的对象，如果在指定时间内，队列一旦有数据可取，则立即返回队列中的数据。否则知道时间超时还没有数据可取，返回失败。
• take():取走BlockingQueue里排在首位的对象,若BlockingQueue为空,阻断进入等待状态直到BlockingQueue有新的数据被加入。
• drainTo():一次性从BlockingQueue获取所有可用的数据对象（还可以指定获取数据的个数），通过该方法，可以提升获取数据效率；不需要多次分批加锁或释放锁。

实现

这里使用Springboot搭建一个微服务作为启动程序。 并定时对消息进行消费。

通过阻塞队列的方式，实现消息的异步处理。

阻塞队列

BlockingQueueMessage.java 

定义一个LinkedBlockingQueue队列，并设置队列长度为5.

public class BlockingQueueMessage {
    public static BlockingQueue queue = new LinkedBlockingQueue<>(5);
}

队列生产者

这里定时器用于模拟日志的产生。

队列生产者：每一秒钟产生一条日志消息并放入队列中

Producer.java

@Component
public class Producer {

    private static AtomicInteger count = new AtomicInteger();

    @Scheduled(fixedDelay = 1000)
    public void producerMessage1() {
        offer("张三");
    }

    @Scheduled(fixedDelay = 1000)
    public void producerMessage2() {
        offer("李四");
    }

    @Scheduled(fixedDelay = 1000)
    public void producerMessage3() {
        offer("王五");
    }

    private void offer(String name){
        try {
            String str = String.valueOf(count.incrementAndGet());
            System.out.println(name + "生产消息：" + str);
            BlockingQueueMessage.queue.offer(str, 2, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

队列消费者

这里定时器用于模拟消费产生的日志信息，获取到后可以进行入库等操作。

队列消费者：此处使用了whiile循环，如果能获取到队列，则消费完后继续获取，当获取到队列的消息msg为null时，代表现在队列中已经已经没有消息，则跳出循环，3秒之后定时器再继续进行消费。BlockingQueueMessage.queue.poll(2, TimeUnit.SECONDS)设置了阻塞队列获取时等待超时时间为2秒。

Consumer.java

@Component
public class Consumer {

    @Scheduled(fixedDelay = 3000)
    public void consumerMessage() {
        boolean isRunning = true;
        while (isRunning) {
            try {
                String msg = BlockingQueueMessage.queue.poll(2, TimeUnit.SECONDS);
                if (null != msg) {
                    System.out.println("接收到的消息：" + msg);
                } else {
                    isRunning = false;
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

springboot启动类

启动类上面需要增加@EnableScheduling注解，否则定时器不生效。

QueueApplication.java

@SpringBootApplication
@EnableScheduling
public class QueueApplication {
    public static void main(String[] args) {
        SpringApplication.run(QueueApplication.class);
    }
}

maven依赖只需引入

        
            org.springframework.boot
            spring-boot-starter-web
        

输出结果

张三生产消息：1
李四生产消息：2
王五生产消息：3
张三生产消息：4
李四生产消息：5
王五生产消息：6
张三生产消息：7
李四生产消息：8
---接收到的消息---：1
---接收到的消息---：2
---接收到的消息---：3
---接收到的消息---：4
---接收到的消息---：5
王五生产消息：9
张三生产消息：10
李四生产消息：11
王五生产消息：12
张三生产消息：13
李四生产消息：14
王五生产消息：15
张三生产消息：16
---接收到的消息---：9
---接收到的消息---：10
---接收到的消息---：11
---接收到的消息---：12
---接收到的消息---：13

 

一看结果，立马发现不对，收到的消息丢失了呢？

因为这里设置了LinkedBlockingQueue长度为5，当队列中消息大于长度时，则无法继续写入队列，只有当队列被消费后才可以继续存入。所以这个消息长度最好是可以设置的，比如从配置文件中获取。

优化

springboot静态变量赋值

Constants.java

@Component
public class Constants {

    //这里可以给默认值，也可以不给
    public static int queueNum = 5;

    //set方法一定不能是static的，否则无效,因为静态方法是在编译时就初始化的
    @Value("${queueNum}")
    public void setQueueNum(int queueNum) {
        Constants.queueNum = queueNum;
    }
}

application.yml

queueNum: 10

BlockingQueueMessage.java 

将队列数量改为从变量中获取.

public class BlockingQueueMessage {
    public static BlockingQueue queue = new LinkedBlockingQueue<>(Constants.queueNum);
}

重新启动项目，获得结果，收到消息完整。

张三生产消息：1
李四生产消息：2
王五生产消息：3
张三生产消息：4
李四生产消息：5
王五生产消息：6
张三生产消息：7
李四生产消息：8
王五生产消息：9
---接收到的消息---：1
---接收到的消息---：2
---接收到的消息---：3
---接收到的消息---：4
---接收到的消息---：5
---接收到的消息---：6
---接收到的消息---：7
---接收到的消息---：8
---接收到的消息---：9

常见的BlockingQueue

1. ArrayBlockingQueue

　　基于数组的阻塞队列实现，在ArrayBlockingQueue内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。

　　ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。Doug Lea之所以没这样去做，也许是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧，以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。 ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。

2. LinkedBlockingQueue

　　基于链表的阻塞队列，同ArrayListBlockingQueue类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。

　　作为开发者，我们需要注意的是，如果构造一个LinkedBlockingQueue对象，而没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX_VALUE），这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。

　　ArrayBlockingQueue和LinkedBlockingQueue是两个最普通也是最常用的阻塞队列，一般情况下，在处理多线程间的生产者消费者问题，使用这两个类足以。

3. DelayQueue

　　DelayQueue中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。DelayQueue是一个没有大小限制的队列，因此往队列中插入数据的操作（生产者）永远不会被阻塞，而只有获取数据的操作（消费者）才会被阻塞。

使用场景：

　　DelayQueue使用场景较少，但都相当巧妙，常见的例子比如使用一个DelayQueue来管理一个超时未响应的连接队列。

4. PriorityBlockingQueue

　　基于优先级的阻塞队列（优先级的判断通过构造函数传入的Compator对象来决定），但需要注意的是PriorityBlockingQueue并不会阻塞数据生产者，而只会在没有可消费的数据时，阻塞数据的消费者。因此使用的时候要特别注意，生产者生产数据的速度绝对不能快于消费者消费数据的速度，否则时间一长，会最终耗尽所有的可用堆内存空间。在实现PriorityBlockingQueue时，内部控制线程同步的锁采用的是公平锁。

5. SynchronousQueue

　　一种无缓冲的等待队列，类似于无中介的直接交易，有点像原始社会中的生产者和消费者，生产者拿着产品去集市销售给产品的最终消费者，而消费者必须亲自去集市找到所要商品的直接生产者，如果一方没有找到合适的目标，那么对不起，大家都在集市等待。相对于有缓冲的BlockingQueue来说，少了一个中间经销商的环节（缓冲区），如果有经销商，生产者直接把产品批发给经销商，而无需在意经销商最终会将这些产品卖给那些消费者，由于经销商可以库存一部分商品，因此相对于直接交易模式，总体来说采用中间经销商的模式会吞吐量高一些（可以批量买卖）；但另一方面，又因为经销商的引入，使得产品从生产者到消费者中间增加了额外的交易环节，单个产品的及时响应性能可能会降低。

声明一个SynchronousQueue有两种不同的方式，它们之间有着不太一样的行为。公平模式和非公平模式的区别:

• 如果采用公平模式：SynchronousQueue会采用公平锁，并配合一个FIFO队列来阻塞多余的生产者和消费者，从而体系整体的公平策略；
• 但如果是非公平模式（SynchronousQueue默认）：SynchronousQueue采用非公平锁，同时配合一个LIFO队列来管理多余的生产者和消费者，而后一种模式，如果生产者和消费者的处理速度有差距，则很容易出现饥渴的情况，即可能有某些生产者或者是消费者的数据永远都得不到处理。 　　 

感谢您的阅读，如果您觉得阅读本文对您有帮助，请点一下“推荐”按钮。本文欢迎各位转载，但是转载文章之后必须在文章开头给出原文链接

转载于:https://www.cnblogs.com/wenjunwei/p/10411444.html