tomcat 请求分析 Processor和Request复用
tomcat 请求分析 Processor和Request复用
参考
Tomcat详解（5）---Connector 分析该文讲解了BIO、NIO下Connector的行为、
前置知识
本文将以BIO，HTTP1.1的视角来阅读源码。 你需要知道Connector的Acceptor线程接收新连接(socket)，会创建SocketProcessor来处理后续请求。如果不知道，请阅读：
本文将讲解接收新连接后，SocketProcessor如何处理后续请求的，以及"Processor"和"Request"的复用。图解如下：
JIoEndpoint.SocketProcessor
在获取新连接后，SocketProcessor是用来处理一次请求的。 我们先记住一个概念：
- 一个SocketProcessor用来处理一次请求。这次请求结束后，SocketProcessor线程就死亡。下次请求是由另一个SocketProcessor线程处理的。
- 上一个SocketProcessor死亡前会创建一个新的SocketProcessor，把与请求参数相关的内存清空(其实就是重置清空Request所有参数，而不是释放内存)连接，并把连接递交给新的SocketProcessor。
我们来看看SocketProcessor.run：
@Override
public void run() {
synchronized (socket) {
try {
SocketState state = SocketState.OPEN;
...
if ((state != SocketState.CLOSED)) {
if (status == null) {
state = handler.process(socket, SocketStatus.OPEN_READ);
} else {
state = handler.process(socket,status);
}
}
...
} finally {
if (launch) {
try {
getExecutor().execute(new SocketProcessor(socket, SocketStatus.OPEN_READ));
}
...
}
}
}
socket = null;
// Finish up this request
}
}做的事情概括如下：
-
handler.process让handler(此处是Http11Protocol.Http11ConnectionHandler)处理具体事务 -
getExecutor().execute(...)创建一个新的SocketProcessor，交给线程池。 - 离开synchronized代码块，结束生命周期。
(synchronized用来对socket进行同步，毕竟会在新旧SocketProcessor之间移交)
然后我们要分析handler.process的行为。
Http11Protocol.Http11ConnectionHandler
其process方法是继承自AbstractProtocol的，我们分析一下：
public SocketState process(SocketWrapper<S> wrapper,
SocketStatus status) {
...
S socket = wrapper.getSocket();
...
try {
if (processor == null) {
processor = recycledProcessors.poll();
}
if (processor == null) {
processor = createProcessor();
}
SocketState state = SocketState.CLOSED;
do {
...
else if (state == SocketState.ASYNC_END) {
state = processor.asyncDispatch(status);
getProtocol().endpoint.removeWaitingRequest(wrapper);
if (state == SocketState.OPEN) {
state = processor.process(wrapper);
}
}
...
else {
state = processor.process(wrapper);
}
} while (...);
if (state == SocketState.LONG) {
...
} else if (state == SocketState.OPEN) {
// In keep-alive but between requests. OK to recycle
// processor. Continue to poll for the next request.
connections.remove(socket);
release(wrapper, processor, false, true);
}
...
return state;
}
catch (Throwable e) {
...
}
...
}我先说明几个变量/函数的用途，以便讲解：
recycledProcessors是一个并发队列，它所存的元素是用来处理接下来的请求的。通过recycledProcessors.poll();取出一个processor(如果没有则调用createProcessor()创建一个)，调用processor.process处理后面的请求，最后再调用release(wrapper, processor, false, true);把其内各个变量重置清空(而不是释放内存。这是为了避免反复申请内存)。
关于release(wrapper, processor, false, true);重置变量这一点，我进一步说明。让我们看下Http11Protocol.Http11ConnectionHandler.release：
public void release(SocketWrapper<Socket> socket,
Processor<Socket> processor, boolean isSocketClosing,
boolean addToPoller) {
processor.recycle(isSocketClosing); // 重置清空变量
recycledProcessors.offer(processor); // 归还给recycledProcessors,供下次使用
}关于两行函数调用的作用，我加注释说明了。我们再看recycle的实现。processor类型是Http11Processor，但recycle是在父类AbstractHttp11Processor里实现的： 其函数大致如下：
@Override
public final void recycle(boolean isSocketClosing) {
getAdapter().checkRecycled(request, response);
if (.. != null) {
getXXX().recycle();
}
... = null
.. = -1;
.. = false;
resetErrorState();
recycleInternal(); // 空
}
@Override
protected void recycleInternal() {
// Recycle
this.socketWrapper = null;
// Recycle ssl info
sslSupport = null;
}就是通过调用recycle()、设为-1或false，把一堆变量给重置为初始状态，但涉及数组的内存都没有释放掉。如果你还是不确定recycle()的行为，可自行跟踪查看，没必要在此耗费太多笔墨。
我始终把recycle翻译为“重置清除”，而不是“回收”，是因为“回收”可能会带来误导，让读者以为内存被回收释放了。实际上，为了避免反复申请内存，大部分的变量、数组内存都没释放。
我们取getInputBuffer().recycle();看下源码AbstractInputBuffer.recycle：
public void recycle() {
// Recycle Request object
request.recycle();
...
}其中涉及了request的重置。说明Request是会回收，循环利用的
图片总结
总结
该文明确了以下几点：
- socket建立后，会在SocketProcessor之间传递，此处SocketProcessor的功能为"worker"
- BIO中，每个请求由一个线程处理。一个请求处理完毕，将各个变量重置，交给下一个线程等待调度。
- Request、Http11Processor(功能为"processor")都是循环利用的。