首先，先花30秒来了解下Jetty是什么，其实很简单，Jetty和tomcat一样，都是一种servlet引擎，他们都支持标准的servlet规范和javaEE规范。但是相对tomcat来说，Jetty更轻量级。

零、Jetty和tomcat的比较（对比学习）

1. 架构比较

Jetty的架构比Tomcat的更为简单

Jetty的架构是基于Handler来实现的，主要的扩展功能都可以用Handler来实现，扩展简单。

Tomcat的架构是基于容器设计的，进行扩展是需要了解Tomcat的整体设计结构，不易扩展。

2. 性能比较

Jetty和Tomcat性能方面差异不大

Jetty可以同时处理大量连接而且可以长时间保持连接，适合于web聊天应用等等。

Jetty的架构简单，因此作为服务器，Jetty可以按需加载组件，减少不需要的组件，减少了服务器内存开销，从而提高服务器性能。

Jetty默认采用NIO结束在处理I/O请求上更占优势，在处理静态资源时，性能较高

Tomcat适合处理少数非常繁忙的链接，也就是说链接生命周期短的话，Tomcat的总体性能更高。

Tomcat默认采用BIO处理I/O请求，在处理静态资源时，性能较差。

3. 其它比较

Jetty的应用更加快速，修改简单，对新的Servlet规范的支持较好。

Tomcat目前应用比较广泛，对JavaEE和Servlet的支持更加全面，很多特性会直接集成进来。

一、Jetty目录剖析

bin：可执行脚本文件

demo- base：

etc：Jetty模块定义的XML配置文件的目录

lib：Jetty依赖的库文件

logs：Jetty的日志目录

modules：Jetty的模块

resources：外部资源配置文件的目录

webapps：项目WAR文件的目录还需要关心根目录下的一个文件：start.d（Wondows系统是start.ini文件），它定义了Jetty的活动模块。

二、基本配置

1、修改Jetty的端口

Jetty默认使用8080端口，要让它使用其他端口（如7070），那么编辑start.d（Wondows系统是start.ini文件），找到jetty.http.port行，修改为：

## Connector port to listen on

jetty.http.port=7070

保存并退出，再重启Jetty。

2、修改webapps目录

Jetty下的webapps是默认的Web项目的部署目录，如果想修改此目录，可修改start.d配置文件（start.ini），移除以下行的注释符号“#”

# jetty.deploy.monitoredDir=webapps

并把内容修改到你指定的目录。保存并退出，再重启Jetty。

三、Jetty的模块化架构

Jetty运行于模块化的架构之上，这意味着Jetty的功能是以模块的方式运行的，比如HTTP、HTTPS、SSL、日志logging、JMX、JNDI、WebSocket等模块。常用的模块如HTTP、JSP和WebSocket模块都是默认就激活的，而其他如HTTPS、JMX等模块则需要手动激活。

1、单个模块的剖析

Jetty的modules子目录列出了所有的模块，这些模块是扩展名为.mod的文件，它声明了要被激活的JAR文件（在Jetty的lib子目录下）和XML配置文件（在Jetty的etc子目录下），以及其他要作为模块被激活的资源。比如，可以查看modules子目录的logging.mod文件的内容，可以看到，它声明了配置文件是etc/jetty-logging.xml，所需的JAR包在lib/logging处，另外logs目录是必须的。

[ xml]

etc/jetty-logging.xml

[files]

logs/

[lib]

lib/logging/**.jar

resources/

2、通过命令行激活模块

激活Jetty的模块有两种方式。第一种方式是通过命令行激活：

java -jar start.jar --add-to-startd=logging

上面的命令会在Jetty目录下创建logging.ini文件，相关的配置可以在此文件中查到。配置日志后，可以再次启动Jetty，并可以查看到日志模块是激活了的。

3、通过配置文件start.ini激活模块

第二种方式是通过配置文件start.ini激活模块

--module=logging

这种方式和前一种相似，且更常用。

4、配置模块

正如上面提到的，mod文件声明了相关的XML配置文件，在Jetty的etc子目录下，可以通过这些配置文件来配置模块。比如日志模块声明了相关的配置文件是jetty-logging.xml，可以通过修改此配置文件来调整日志。

四、接受请求

Jetty 作为一个独立的 Servlet 引擎可以独立提供 Web 服务，但是它也可以与其他 Web 应用服务器集成，所以它可以提供基于两种协议工作，一个是 HTTP，一个是 AJP 协议。如果将 Jetty 集成到 Jboss 或者 Apache，那么就可以让 Jetty 基于 AJP 模式工作。下面分别介绍 Jetty 如何基于这两种协议工作，并且它们如何建立连接和接受请求的。

1、基于HTTP

2、基于AJP

3、NIO处理方式

Jetty 建立客户端连接到处理客户端的连接也支持 NIO 的处理方式，其中 Jetty 的默认 connector 就是 NIO 方式。

关于 NIO 的工作原理可以参考 developerworks 上关于 NIO 的文章，通常 NIO 的工作原型如下：

Selector selector = Selector.open();

ServerSocketChannel ssc = ServerSocketChannel.open();

ssc.configureBlocking( false );

SelectionKey key = ssc.register( selector, SelectionKey.OP_ACCEPT );

ServerSocketChannel ss = (ServerSocketChannel)key.channel();

SocketChannel sc = ss.accept();

sc.configureBlocking( false );

SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ );

Set selectedKeys = selector.selectedKeys();

创建一个 Selector 相当于一个观察者，打开一个 Server 端通道，把这个 server 通道注册到观察者上并且指定监听的事件。然后遍历这个观察者观察到事件，取出感兴趣的事件再处理。这里有个最核心的地方就是，我们不需要为每个被观察者创建一个线程来监控它随时发生的事件。而是把这些被观察者都注册一个地方统一管理，然后由它把触发的事件统一发送给感兴趣的程序模块。这里的核心是能够统一的管理每个被观察者的事件，所以我们就可以把服务端上每个建立的连接传送和接受数据作为一个事件统一管理，这样就不必要每个连接需要一个线程来维护了。

这里需要注意的地方时，很多人认为监听 SelectionKey.OP_ACCEPT 事件就已经是非阻塞方式了，其实 Jetty 仍然是用一个线程来监听客户端的连接请求，当接受到请求后，把这个请求再注册到 Selector 上，然后才是非阻塞方式执行。这个地方还有一个容易引起误解的地方是：认为 Jetty 以 NIO 方式工作只会有一个线程来处理所有的请求，甚至会认为不同用户会在服务端共享一个线程从而会导致基于 ThreadLocal 的程序会出现问题，其实从 Jetty 的源码中能够发现，真正共享一个线程的处理只是在监听不同连接的数据传送事件上，比如有多个连接已经建立，传统方式是当没有数据传输时，线程是阻塞的也就是一直在等待下一个数据的到来，而 NIO 的处理方式是只有一个线程在等待所有连接的数据的到来，而当某个连接数据到来时 Jetty 会把它分配给这个连接对应的处理线程去处理，所以不同连接的处理线程仍然是独立的。

Jetty 的 NIO 处理方式和 Tomcat 的几乎一样，唯一不同的地方是在如何把监听到事件分配给对应的连接的处理方式。从测试效果来看 Jetty 的 NIO 处理方式更加高效。下面是 Jetty 的 NIO 处理时序图：

好了，今天Jetty的简单学习与教程就到这里，觉得有收获的同学可以收藏关注。本头条号内有多个专题，如【数据结构】、【netty专题】、【dubbo专题】、【mysql优化专题】、【redis专题】、【高并发专题】等优质好文。一起学习，共同进步。