Jetty 服务器架构分析(下)

说过了服务器启动，最后来看一下请求处理过程，服务器启动好后，处于待命状态，请求来了，请求处理过程由分两个建阶段：

• 请求连接建立过程(以NIO为例)

前面有提到，从线程池中固定分配了一个线程专门用于等待新连接，就是上图的监听线程，没有请求来时，该线程是阻塞在accept()方法上的，当新连接来建立连接时，accept方法分配了一个socket，并将其设置为nonblocking,最后要做的就是将该socket丢给某个Acceptor线程(基本上机会均等)处理，然后立马返回继续处于接受状态，可以这个线程的工作是相当的简单的，效率那也是相当的高。

Acceptor线程有很多个(全部来自于线程池，并且固定分配出来，基于jetty.xml配置中的Acceptors配置数量)，每个线程都维护了一个SelectSet,每个SelectSet又对应了一个Selector,这些线程会检测当前是否有任务来，例如检测changes队列中是否有任务，有并且是新连接，那么就迅速建立一个endpoint点负责管理这个socket，并注册read事件，后续该selector就会负责该连接的read事件监听。

对于连接很多的情况，这里分很多个Selector来分别监听，提高了效率。

• 请求数据处理过程(以NIO为例)

当数据发送过来时，Selector检测到read事件，会立马调用endpoint的schedule()方法，该方法目的就是从线程池分配一个worker线程专门来处理这个read事件，而自己却立马返回继续监听，可见，这里也是一个高效的处理方式。

业务线程分配成功后，负责请求的读取以及解析，如果请求是完整的，那么就开始调用Server的handle方法(server本身就是一个handler)，开始handler的处理，最后调用到SerlvetHandler，最终交给Servlet、Filter，开始了我们的自己应用。

后记

1、 Jetty的模块化做得非常好，可以随时替换其中的绝大部分关键部件，也可以拆掉，例如不需要处理Session，可以简单配置一下即可搞定，不需要处理Servlet,可以不用配置ServletHandler.

2、 jetty 采用非阻塞IO时，我们可以看到从头到尾的几次线程池分配情况，第一次分配一个固定线程监听新连接，第二次分配N个固定线程监听read事件（这里的N个线程在7.3版本中配置文件中配置acceptors数量即可，也就是说会从线程池固定分配N个线程出来），第三次分配线程就是read事件到来之后，立即分配一个业务线程(这个是临时的，用了要回收)处理数据直到我们应用返回结果。最后有一个地方上面都没有说到，那就是超时等原因要关闭连接时，是分配了临时线程来处理这些事情

3、 模块化、切分task

4、 小，真的很小

延伸阅读

1、 Jetty continuations

2、 Tomcat comet