提高系统吞吐量，DeferredResult 到底有多强？

大家都知道，Callable和DeferredResult​可以用来进行异步请求处理。利用它们，我们可以异步生成返回值，在具体处理的过程中，我们直接在controller​中返回相应的Callable​或者DeferredResult​，在这之后，servlet线程将被释放，可用于其他连接；DeferredResult​另外会有线程来进行结果处理，并setResult。,在正式开始之前，我们先做一点准备工作，在项目中新建了一个base模块。其中包含一些提供基础支持的java类，在其他模块中可能会用到。,我们定义了一个ResponseMsg的实体类来作为我们的返回值类型：,非常简单，里面包含了code、msg和data三个字段，其中data为泛型类型。另外类的注解Data、NoArgsConstructor和AllArgsConstructor都是lombok提供的简化我们开发的，主要功能分别是，为我们的类生成set和get方法，生成无参构造器和生成全参构造器。使用idea进行开发的童鞋可以装一下lombok的支持插件。另外，lombok的依赖参见：,我们建立了一个TaskService，用来为阻塞调用和Callable调用提供实际结果处理的。代码如下：,可以看到，里面实际提供服务的是getResult方法，这边直接返回一个new ResponseMsg(0,“操作成功”,“success”)。但是其中又特意让它sleep了30秒，模拟一个耗时较长的请求。,平时我们用的最普遍的还是阻塞调用，通常请求的处理时间较短，在并发量较小的情况下，使用阻塞调用问题也不是很大。关注公众号：码猿技术专栏，回复关键词：1111 获取阿里内部Java性能调优手册！阻塞调用实现非常简单，我们首先新建一个模块blockingtype​，里面只包含一个controller​类，用来接收请求并利用TaskService来获取结果。,我们请求的是getResult​方法，其中调用了taskService​，这个taskService​我们是注入得到的。关于怎么跨模块注入的，其实也非常简单，在本模块，加入对其他模块的依赖就可以了。比如这里我们在blockingtype的pom.xml文件中加入对base模块的依赖：,然后我们看一下实际调用效果，这里我们设置端口号为8080，启动日志如下：,可以看到顺利启动了，那么我们就来访问一下:,等待了大概30秒左右，得到json数据：,,然后我们来看看控制台的日志：,可以看到在“ResponseMsg result = taskService.getResult();​”的时候是阻塞了大约30秒钟，随后才执行它后面的打印语句“log.info(“接收任务线程完成并退出”);”。,涉及到较长时间的请求处理的话，比较好的方式是用异步调用，比如利用Callable​返回结果。异步主要表现在，接收请求的servlet​可以不用持续等待结果产生，而可以被释放去处理其他事情。当然，在调用者来看的话，其实还是表现在持续等待30秒。这有利于服务端提供更大的并发处理量。这里我们新建一个callabledemo​模块，在这个模块中，我们一样只包含一个TaskController​，另外也是需要加入base模块的依赖。只不过这里我们的返回值不是ResponseMsg​类型了，而是一个Callable类型。,在里面，我们创建了一个Callable​类型的变量result，并实现了它的call方法，在call方法中，我们也是调用taskService的getResult​方法得到返回值并返回。下一步我们就运行一下这个模块，这里我们在模块的application.yml中设置端口号为8081:,启动，可以看到控制台的消息：,完美启动了，然后我们还是一样，访问一下：,在大约等待了30秒左右，我们在浏览器上得到json数据：,和阻塞调用的结果一样——当然一样啦，都是同taskService中得到的结果。然后我们看看控制台的消息：,很显然，这里的消息出现的顺序和阻塞模式有所不同了，这里在“接收请求，开始处理…”之后直接打印了“接收任务线程完成并退出”。而不是先出现“任务处理完成”后再出现“接收任务线程完成并退出”。这就说明，这里没有阻塞在从taskService​中获得数据的地方，controller中直接执行后面的部分（这里可以做其他很多事，不仅仅是打印日志）。,前面铺垫了那么多，还是主要来说DeferredResult​的；和Callable​一样，DeferredResult​也是为了支持异步调用。两者的主要差异，Sunny觉得主要在DeferredResult​需要自己用线程来处理结果setResult​，而Callable​的话不需要我们来维护一个结果处理线程。总体来说，Callable​的话更为简单，同样的也是因为简单，灵活性不够；相对地，DeferredResult​更为复杂一些，但是又极大的灵活性。在可以用Callable​的时候，直接用Callable​；而遇到Callable​没法解决的场景的时候，可以尝试使用DeferredResult​。这里Sunny将会设计两个DeferredResult使用场景。,看起来非常简单，成员变量又taskId和taskResult​，前者是int类型，后者为我们的DeferredResult​类型，它的泛型类型为ResponseMsg​，注意这里用到ResponseMsg​，所以也需要导入base模块的依赖。另外注解之前已经说明了，不过这里再提一句，@Data​注解也包含了toString的重写，但是这里为了知道具体的ResponseMsg的内容，Sunny特意手动重写。看完Task类型，我们再来看看任务队列。,这里我们将它作为一个bean，之后会在其他bean中注入，这里实际的队列为成员变量queue，它是LinkedBlockingDeque​类型的。还有一个成员变量为taskId，是用于自动生成任务id的，并且在加入任务的方法中实现自增，以确保每个任务的id唯一性。方法的话又put和take方法，分别用于向队列中添加任务和取出任务；其中，对queue的操作，分别用了offer和poll，这样是实现一个非阻塞的操作，并且在队列为空和队列已满的情况下不会抛出异常。另外，大家实现的时候，可以考虑使用ConcurrentLinkedQueue​来高效处理并发，因为它属于无界非阻塞队列，使用过程中需要考虑可能造成的OOM问题。Sunny这里选择阻塞队列LinkedBlockingDeque​，它底层使用加锁进行了同步；但是这里使用了TaskQueue进行封装，处理过程中有一些额外操作，调用时需要加锁以防发生某些意料之外的问题。,然后我们来看步骤1中的，启动一个持续从任务队列中获取任务的线程的具体实现。,这里，我们注入了TaskQueue​，成员变量比较简单并且有注释，不再说明，主要来看方法。先看一下最后一个方法getRandomStr​，很显然，这是一个获得长度为len的随机串的方法，访问限定为private，为类中其他方法服务的。然后我们看init方法，它执行的其实就是开启了一个线程并且执行execute方法，注意一下它上面的@PostContruct​注解，这个注解就是在这个bean初始化的时候就执行这个方法。所以我们需要关注的实际逻辑在execute​方法中。可以看到，在execute​方法中，用了一个while(true)​来保证线程持续运行。因为是并发环境下，考虑对taskQueue​加锁，从中取出任务；如果任务不为空，获取用getRandomStr​生成一个随机结果并用setResult​方法进行返回。最后可以看到，利用random生成来一个[0,10)​的随机数，并让线程sleep相应的秒数。这里注意一下，需要设定一个时间间隔，否则，先线程持续跑会出现CPU负载过高的情况。接下来我们就看看controller是如何处理的。,这里我们同样注入了taskQueue​。请求方法就只有一个getResult​，返回值为DeferredResult<ResponseMsg>​。这里我们首先创建了DeferredResult​对象result并且设定超时时间和超时返回结果；随后设定result的onTimeout和onCompletion​方法，其实就是传入两个Runnable​对象来实现回调的效果；之后就是加锁并且将result加入任务队列中。总体来说，场景不算非常复杂，看到这里大家应该都能基本了解了。然后我们来跑一下测试一下。我们在application.yml中设定端口为8082:,启动模块，控制台信息如下：,首先程序完美启动，这没有问题，然后我们注意这几条信息：,这说明我们TaskExecute中已经成功启动了持续获取任务的线程。接着，我们还是访问一下：,这一回等待了若干秒就出现了结果：,可以看到我们的随机串是CEUO2lmMJr。再一次请求又会出现不同的随机串。再看一下我们控制台的相关信息：,也是符合我们的预期，请求进来进入队列中，由TaskExecute获取请求并进行处理结果返回。,首先我们来看看DeferredResult的集合类：,非常简单，只包含了一个HashSet的成员变量。这里可以考虑用ConcurrentHashMap​来实现高效并发，Sunny这里简单实用HashSet，配合加锁实现并发处理。然后我们看看发起调用的Controller代码：,和场景一中有些类似，但是注意这里在onTimeout和onCompletion​中都多了一个移除元素的操作，这也就是每次调用结束，需要将集合中的DeferredResult​对象移除，即集合中保存的都是等待请求结果的DeferredResult​对象。然后我们看处理请求结果的Controller：,看起来非常简单，只是做了两个操作，接收得到的参数并利用参数生成一个ResponseMsg​对象，随后将集合中的所有DeferredResult​都设定结果为根据参数生成的ResponseMsg对象。最后返回一个提示：成功设置结果…好了，话不多说，我们来启动测试验证一下。我们说一下验证的过程，我们同时打开两个请求，然后再设定一个结果，最后两个请求都会得到这个结果。当然同时多个或者一个请求也是一样。这里有一个地方需要注意一下：,这样，我们考虑从两个浏览器中发送请求：,然后随便找其中一个，发送请求来设置结果：,首先我们先启动模块，可以从控制台中看到完美启动管理了：,完美启动，接下来Sunny在火狐中发起一个请求,,可以看到正在等待请求结果。随后我们在谷歌浏览器中发起请求,,两个请求同时处于等待状态，这时候我们看一下控制台信息：,可以看到两个请求都已经接收到了，并且加入了队列。这时候，我们再发送一个设置结果的请求。,,随后我们查看两个调用请求的页面，发现页面已经不在等待状态中了，都已经得到了结果。,,,另外，再给大家展示一下超时的结果，即我们发起调用请求，但是不发起设置结果的请求，等待时间结束。,,查看控制台信息：