线程分类
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案例
代码语言：javascript复制@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
代码语言：javascript复制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
代码语言：javascript复制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对象拿到。
代码语言：javascript复制public void complete() {
//检查状态合法性，我们先忽略这句
check();
//调用Request对象的action方法，其实就是通知连接器，这个异步请求处理完了
request.getCoyoteRequest().action(ActionCode.ASYNC_COMPLETE, null);
}调用了Request#action。action里则调用了Processor#processSocketEvent，并传入操作码OPEN_READ。
代码语言：javascript复制case ASYNC_COMPLETE: {
clearDispatches();
if (asyncStateMachine.asyncComplete()) {
processSocketEvent(SocketEvent.OPEN_READ, true);
}
break;
}processSocketEvent
调用SocketWrapper#processSocket
代码语言：javascript复制protected void processSocketEvent(SocketEvent event, boolean dispatch) {
SocketWrapperBase<?> socketWrapper = getSocketWrapper();
if (socketWrapper != null) {
socketWrapper.processSocket(event, dispatch);
}
}SocketWrapper#processSocket会创建SocketProcessor任务类，并通过Tomcat线程池处理：
代码语言：javascript复制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连接，获取客户端地址，响应给客户端。
