本文主要是介绍Spring MVC 基于阻塞队列 LinkedBlockingQueue 的同步长轮询功能实现，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
标题 Spring MVC 基于阻塞队列 LinkedBlockingQueue 的同步长轮询功能实现，其实本文介绍的也是生产者消费者的一种实现。生产者不必是一个始终在执行的线程，它可以是一个接口，接受客户端的请求，向队列中插入消息；消费者也不必是一个始终在执行的线程，它同样也可以是一个接口，接受客户端的请求，从队列中取出属于自己的消息；看到很多介绍生产者消息者实现的文章，实现场景都很简单，现实应用往往会比较复杂，有一些附加条件，本例中就需要根据消息中的 familyId 来判断消息是不是下发给自己的。
应用场景
本例的应用场景是一个物联网智能家居应用，系统结构图如下：
主要实现的功能是用户通过手机端APP发出设备控制的命令（如：开灯、关灯等）后，设备网关能够实时的获取到控制命令，进而控制设置的状态。
为什么要使用长轮询功能呢？
其实可选的方案有很多种：
1、长轮询
2、长链接
3、Socket
4、WebSocket
5、MQTT
选择长轮询方案是因为其实现的简单性，实现起来与其它的接口基本没有太大的差别。
同步与异步处理模式分析
同步服务模式：
同步服务为每个请求创建单一线程，由此线程完成整个请求的处理：接收消息，处理消息，返回数据；这种情况下服务器资源对所有入栈请求开放，服务器资源被所有入栈请求竞争使用，如果入栈请求过多就会导致服务器资源耗尽宕机，或者导致竞争加剧，资源调度频繁，服务器资源利用效率降低。
异步服务则可以分别设置两个线程队列，一个专门负责接收消息，另一个专门负责处理消息并返回数据，另有一些值守线程负责任务派发和超时监控等工作。在这种情况下无论入栈请求有多少，服务器始终依照自己的能力处理请求，服务器资源消耗始终在一个可控的范围。这种模式的一个问题就是这两个线程队列的大小如何根据机器负载情况动态调整。
异步服务模式：
这种情况下，虽然入栈请求以消息队列的方式被异步处理但每个请求内部却是采用阻塞的方式访问外部资源，如果外部资源访问速度过慢，可能导致请求处
这篇关于Spring MVC 基于阻塞队列 LinkedBlockingQueue 的同步长轮询功能实现的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
