Java Servlet3.0异步处理问题
通过本篇文章主要给大家讲解了在JAVA开发中Servlet3.0异步处理遇到的问题以及处理办法，以下是具体内容：
Servlet3.0开始提供了AsyncContext用来支持异步处理请求，那么异步处理请求到底能够带来哪些好处？
Web容器一般来说处理请求的方式是：为每个request分配一个thread。我们都知道thread的创建不是没有代价的，Web容器的threadpool都是有上限的。
那么一个很容易预见的问题就是，在高负载情况下，threadpool都被占着了，那么后续的request就只能等待，如果运气不好客户端会报等待超时的错误。
在AsyncContext出现之前，解决这个问题的唯一办法就是扩充Web容器的threadpool。
但是这样依然有一个问题，考虑以下场景：
有一个web容器，线程池大小200。有一个webapp，它有两个servlet，Servlet-A处理单个请求的时间是10s，Servlet-B处理单个请求的时间是1s。
现在遇到了高负载，有超过200个request到Servlet-A，如果这个时候请求Servlet-B就会等待，因为所有HTTPthread都已经被Servlet-A占用了。
这个时候工程师发现了问题，扩展了线程池大小到400，但是负载依然持续走高，现在有400个request到Servlet-A，Servlet-B依然无法响应。
看到问题了没有，因为HTTPthread和Workerthread耦合在了一起，所以导致了当大量request到一个耗时操作时，就会将HTTPthread占满，导致整个Web容器就会无法响应。
但是如果使用AsyncContext，我们就可以将耗时的操作交给另一个thread去做，这样HTTPthread就被释放出来了，可以去处理其他请求了。
注意，只有使用AsyncContext才能够达到上面所讲的效果，如果直接newThread()或者类似的方式的，HTTPthread并不会归还到容器。
下面是一个官方的例子：
@WebServlet(urlPatterns={"/asyncservlet"},asyncSupported=true)
publicclassAsyncServletextendsHttpServlet{
/*...SamevariablesandinitmethodasinSyncServlet...*/
@Override
publicvoiddoGet(HttpServletRequestrequest,
HttpServletResponseresponse){
response.setContentType("text/html;charset=UTF-8");
finalAsyncContextacontext=request.startAsync();
acontext.start(newRunnable(){
publicvoidrun(){
Stringparam=acontext.getRequest().getParameter("param");
Stringresult=resource.process(param);
HttpServletResponseresponse=acontext.getResponse();
/*...printtotheresponse...*/
acontext.complete();
}
});
}
}
陷阱
在这个官方例子里，每个HTTPthread都会开启另一个Workerthread来处理请求，然后把HTTPthread就归还给Web容器。但是看AsyncContext.start()方法的javadoc：
Causesthecontainertodispatchathread,possiblyfromamanagedthreadpool,torunthespecifiedRunnable.
实际上这里并没有规定Workerthread到底从哪里来，也许是HTTPthreadpool之外的另一个threadpool？还是说就是HTTPthreadpool？
TheLimitedUsefulnessofAsyncContext.start()文章里写道：不同的Web容器对此有不同的实现，不过Tomcat实际上是利用HTTPthreadpool来处理AsyncContext.start()的。
这也就是说，我们原本是想释放HTTPthread的，但实际上并没有，因为有HTTPthread依然被用作Workerthread，只不过这个thread和接收请求的HTTPthread不是同一个而已。
这个结论我们也可以通过AsyncServlet1和SyncServlet的Jmeterbenchmark看出来，两者的throughput结果差不多。启动方法：启动Main，然后利用Jmeter启动benchmark.jmx（Tomcat默认配置下HTTPthreadpool=200）。
使用ExecutorService
前面看到了Tomcat并没有单独维护Workerthreadpool，那么我们就得自己想办法搞一个，见AsyncServlet2，它使用了一个带Threadpool的ExecutorService来处理AsyncContext。
其他方式
所以对于AsyncContext的使用并没有固定的方式，你可以根据实际需要去采用不同的方式来处理，为此你需要一点Javaconcurrentprogramming的知识。
对于性能的误解
AsyncContext的目的并不是为了提高性能，也并不直接提供性能提升，它提供了把HTTPthread和Workerthread解藕的机制，从而提高Web容器的响应能力。
不过AsyncContext在某些时候的确能够提高性能，但这个取决于你的代码是怎么写的。
比如：Web容器的HTTPthreadpool数量200，某个Servlet使用一个300的Workerthreadpool来处理AsyncContext。
相比Sync方式Workerthreadpool=HTTPthreadpool=200，在这种情况下我们有了300的Workerthreadpool，所以肯定能够带来一些性能上的提升（毕竟干活的人多了）。
相反，如果当Workerthread的数量<=HTTPthread数量的时候，那么就不会得到性能提升，因为此时处理请求的瓶颈在Workerthread。
你可以修改AsyncServlet2的线程池大小，把它和SyncServlet比较benchmark结果来验证这一结论。
一定不要认为Workerthreadpool必须比HTTPthreadpool大，理由如下：
两者职责不同，一个是Web容器用来接收外来请求，一个是处理业务逻辑
thread的创建是有代价的，如果HTTPthreadpool已经很大了再搞一个更大的Workerthreadpool反而会造成过多的Contextswitch和内存开销
AsyncContext的目的是将HTTPthread释放出来，避免被操作长期占用进而导致Web容器无法响应
所以在更多时候，Workerthreadpool不会很大，而且会根据不同业务构建不同的Workerthreadpool。
比如：Web容器threadpool大小200，一个慢速Servlet的Workerthreadpool大小10，这样一来，无论有多少请求到慢速操作，它都不会将HTTPthread占满导致其他请求无法处理。