Tomcat对异步Servlet的支持
Posted JavaEdge.
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Tomcat对异步Servlet的支持相关的知识,希望对你有一定的参考价值。
线程分类
Tomcat启动的线程和Web应用本身启动的线程:
- Tomcat线程池中的线程会调用Servlet#service,叫Tomcat线程
- Web程序在service方法的实现里启动的新线程,叫Web应用线程
当一个新请求到达,Tomcat会从线程池取一个线程处理,该线程会调用你的Web应用,Web应用在处理请求过程中,Tomcat线程会一直阻塞,直到Web应用处理完,才输出响应,最后Tomcat回收该线程。
假如Web应用需很长时间处理一个请求(比如DB查询或等待下游的服务调用返回),则Tomcat线程一直不回收,就会占用系统资源,极端情况下会导致“线程饥饿”,即Tomcat没有更多线程处理新请求了。
怎么办呢?
于是,Servlet 3.0引入异步Servlet:在Web应用里启动一个单独线程执行这些耗时请求,而Tomcat线程立即返回,不再等待Web应用将请求处理完,这样Tomcat线程可立即被回收到线程池,以响应其他请求,降低系统资源消耗。
异步Servlet只能说让Tomcat有机会接收更多请求,但并不能提升服务吞吐量,因为若业务操作本身还是很慢,业务线程池仍会被占满,后面提交的任务还是要等待。
业务处理一般阻塞在I/O等待,越是I/O密集型应用,越需要配置更多线程。
异步Servlet案例
@WebServlet(urlPatterns = {"/async"}, asyncSupported = true)
public class AsyncServlet extends HttpServlet {
// Web应用线程池,用来处理异步Servlet
ExecutorService executor = Executors.newSingleThreadExecutor();
public void service(HttpServletRequest req, HttpServletResponse resp) {
// 1. 调用startAsync或者异步上下文
final AsyncContext ctx = req.startAsync();
//用线程池来执行耗时操作
executor.execute(new Runnable() {
@Override
public void run() {
//在这里做耗时的操作
try {
ctx.getResponse().getWriter().println("Handling Async Servlet");
} catch (IOException e) {}
//3. 异步Servlet处理完了调用异步上下文的complete方法
ctx.complete();
}
});
}
}
通过注解注册Servlet:@WebServlet注解,asyncSupported=true
表明当前的Servlet是一个异步Servlet。
Web应用程序需要调用Request对象的startAsync方法来拿到一个异步上下文AsyncContext。这个上下文保存了请求和响应对象。
Web应用需要开启一个新线程处理耗时操作:处理完成后调用AsyncContext#complete,通知Tomcat,请求已经处理完。
虽然异步Servlet允许用更长的时间来处理请求,但是也有超时限制的,默认是30秒,如果30秒内请求还没处理完,Tomcat会触发超时机制,向浏览器返回超时错误,如果这个时候你的Web应用再调用ctx.complete方法,会得到IllegalStateException。
异步Servlet原理
Tomcat在这个过程的关键:
startAsync方法
创建一个异步上下文AsyncContext对象,保存请求的中间信息,比如Request和Response对象等上下文信息。
这是因为Tomcat的工作线程在request.startAsync调用之后,就直接结束回到线程池中了,线程本身不会保存任何信息。也就是说一个请求到服务端,执行到一半,你的Web应用正在处理,这个时候Tomcat的工作线程没了,这就需要有个缓存能够保存原始的Request和Response对象,而这个缓存就是AsyncContext。
有了AsyncContext,你的Web应用通过它拿到Request和Response对象,拿到Request对象后就可以读取请求信息,请求处理完了还需要通过Response对象将HTTP响应发送给浏览器。
除了创建AsyncContext对象,startAsync还需要完成一个关键任务,那就是告诉Tomcat当前的Servlet处理方法返回时,不要把响应发到浏览器,因为这个时候,响应还没生成呢;并且不能把Request对象和Response对象销毁,因为后面Web应用还要用呢。
在Tomcat中,负责flush响应数据的是CoyoteAdapter,它还会销毁Request对象和Response对象,因此需要通过某种机制通知CoyoteAdapter,具体来说是通过下面这行代码:
this.request.getCoyoteRequest().action(ActionCode.ASYNC_START, this);
你可以把它理解为一个Callback,在这个action方法里设置了Request对象的状态,设置它为一个异步Servlet请求。
连接器调用CoyoteAdapter#service处理请求的,而CoyoteAdapter会调用容器的service,当容器的service方法返回,CoyoteAdapter判断当前的请求是不是异步Servlet请求:
- 如果是,就不会销毁Request和Response对象,也不会把响应信息发到浏览器。
CoyoteAdapter#service
public void service(org.apache.coyote.Request req, org.apache.coyote.Response res) {
//调用容器的service方法处理请求
connector.getService().getContainer().getPipeline().
getFirst().invoke(request, response);
//如果是异步Servlet请求,仅仅设置一个标志,
//否则说明是同步Servlet请求,就将响应数据刷到浏览器
if (request.isAsync()) {
async = true;
} else {
request.finishRequest();
response.finishResponse();
}
//如果不是异步Servlet请求,就销毁Request对象和Response对象
if (!async) {
request.recycle();
response.recycle();
}
}
当CoyoteAdapter#service返回到ProtocolHandler组件,ProtocolHandler判断返回值,如果当前请求是一个异步Servlet请求,它会把当前Socket的协议处理者Processor缓存起来,将SocketWrapper对象和相应的Processor存到Map
private final Map<S,Processor> connections = new ConcurrentHashMap<>();
缓存是因为这个请求接下来还要接着处理,还由原来Processor处理,通过SocketWrapper就能从Map里找到相应Processor。
complete方法
当请求处理完成时,Web应用调用这个方法:把响应数据发送到浏览器。
这事不能由Web应用线程负责,即ctx.complete
不能直接把响应数据发送到浏览器,因为这件事情应该由Tomcat线程处理。
连接器中的Endpoint组件检测到有请求数据达到时,会创建一个SocketProcessor对象交给线程池去处理,因此Endpoint的通信处理和具体请求处理在两个线程里运行。
在异步Servlet场景,Web应用通过调用ctx.complete方法时,也可生成一个新的SocketProcessor任务类,交给线程池处理。
对于异步Servlet请求来说,相应的Socket和协议处理组件Processor都被缓存起来了,并且这些对象都可以通过Request对象拿到。
public void complete() {
//检查状态合法性,我们先忽略这句
check();
//调用Request对象的action方法,其实就是通知连接器,这个异步请求处理完了
request.getCoyoteRequest().action(ActionCode.ASYNC_COMPLETE, null);
}
调用了Request#action。action里则调用了Processor#processSocketEvent,并传入操作码OPEN_READ。
case ASYNC_COMPLETE: {
clearDispatches();
if (asyncStateMachine.asyncComplete()) {
processSocketEvent(SocketEvent.OPEN_READ, true);
}
break;
}
processSocketEvent
调用SocketWrapper#processSocket
protected void processSocketEvent(SocketEvent event, boolean dispatch) {
SocketWrapperBase<?> socketWrapper = getSocketWrapper();
if (socketWrapper != null) {
socketWrapper.processSocket(event, dispatch);
}
}
SocketWrapper#processSocket会创建SocketProcessor任务类,并通过Tomcat线程池处理:
public boolean processSocket(SocketWrapperBase<S> socketWrapper,
SocketEvent event, boolean dispatch) {
if (socketWrapper == null) {
return false;
}
SocketProcessorBase<S> sc = processorCache.pop();
if (sc == null) {
sc = createSocketProcessor(socketWrapper, event);
} else {
sc.reset(socketWrapper, event);
}
// 线程池运行
Executor executor = getExecutor();
if (dispatch && executor != null) {
executor.execute(sc);
} else {
sc.run();
}
}
createSocketProcessor函数的第二个参数SocketEvent,这里传入OPEN_READ,控制SocketProcessor的行为,不需要再把请求发送到容器进行处理,只需要向浏览器端发送数据,并且重新在这个Socket上监听新的请求。
总结
非阻塞I/O模型可利用很少线程处理大量连接,提高并发度,本质就是通过一个Selector线程查询多个Socket的I/O事件,减少线程的阻塞等待。
异步Servlet机制也是减少线程的阻塞等待,将Tomcat线程和业务线程分开,Tomca线程不再等待业务代码执行完成。
适用场景
发现Tomcat的线程不够了,大量线程阻塞在等待Web应用的处理上,而Web应用又没有优化的空间了,确实需要长时间处理,可尝鲜。
FAQ
异步sevlet内部的业务应用中的IO也需要异步IO支持吧,就像vertx的异步模式,否则都堵塞在业务线程上就没意义了。所以Springboot webflux提供全异步的方案。
一个请求进来之后,若采用异步Servlet处理,原来的请求Tomcat线程被回收,那本身这个请求要再相应给客户端,怎么知道是哪个客户端请求过来的,是根据请求信息,一个请求绑定了一个TCP连接,获取客户端地址,响应给客户端。
以上是关于Tomcat对异步Servlet的支持的主要内容,如果未能解决你的问题,请参考以下文章
Servlet 3.0笔记之异步请求Comet推送iFrame示范