eclipse运行tomcat_eclipse运行tomcat

Tomcat是一个小型的轻量级应用服务器，也是JavaEE开发人员最常用的服务器之一。不过，许多开发人员不知道的是，Tomcat Connector(Tomcat连接器)有bio、nio、apr三种运行模式，那么这三种运行模式有什么区别呢，我们又如何修改Tomcat Connector的运行模式来提高Tomcat的运行性能呢？

下面，我们先大致了解Tomcat Connector的三种运行模式。

bio

bio(blocking I/O)，顾名思义，即阻塞式I/O操作，表示Tomcat使用的是传统的Java I/O操作(即java.io包及其子包)。Tomcat在默认情况下，就是以bio模式运行的。遗憾的是，就一般而言，bio模式是三种运行模式中性能最低的一种。我们可以通过Tomcat Manager来查看服务器的当前状态。【点击这里可以查看Tomcat Manager用户配置的相关信息】

nio

nio(new I/O)，是Java SE 1.4及后续版本提供的一种新的I/O操作方式(即java.nio包及其子包)。Java nio是一个基于缓冲区、并能提供非阻塞I/O操作的Java API，因此nio也被看成是non-blocking I/O的缩写。它拥有比传统I/O操作(bio)更好的并发运行性能。要让Tomcat以nio模式来运行也比较简单，我们只需要在Tomcat安装目录/conf/server.xml文件中将如下配置：

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />

中的protocol属性值改为org.apache.coyote.http11.Http11NioProtocol即可：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443" />

此时，我们就可以在Tomcat Manager中看到当前服务器状态页面的HTTP协议的Connector运行模式已经从http-bio-8080变成了http-nio-8080。

apr

apr(Apache Portable Runtime/Apache可移植运行时)，是Apache HTTP服务器的支持库。你可以简单地理解为，Tomcat将以JNI的形式调用Apache HTTP服务器的核心动态链接库来处理文件读取或网络传输操作，从而大大地提高Tomcat对静态文件的处理性能。 Tomcat apr也是在Tomcat上运行高并发应用的首选模式。如果我们的Tomcat不是在apr模式下运行，在启动Tomcat的时候，我们可以在日志信息中看到类似如下信息：

2013-8-6 16:17:49 org.apache.catalina.core.AprLifecycleListener init
信息: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: xxx/xxx(这里是路径信息)

Tomcat apr运行模式的配置是三种运行模式之中相对比较麻烦的一种。据官方文档所述，Tomcat apr需要以下三个组件的支持：

APR library[APR库]
JNI wrappers for APR used by Tomcat (libtcnative)[简单地说，如果是在Windows操作系统上，就是一个名为tcnative-1.dll的动态链接库文件]
OpenSSL libraries[OpenSSL库]

此外，与配置nio运行模式一样，也需要将对应的Connector节点的protocol属性值改为org.apache.coyote.http11.Http11AprProtocol。不过，上述繁琐的操作都是Tomcat 7.0.30之前的版本才需要这样配置，从Tomcat 7.0.30版本开始，Tomcat已经自带了tcnative-1.dll等文件，并且默认就是在Tomcat apr模式下运行，因此我们只需要下载最新版本的Tomcat直接使用即可。

此外，即使不使用Tomcat Manager，我们也可以区分出Tomcat当前的运行模式。如果以不同的Connector模式启动，在Tomcat的启动日志信息中一般会包含类似如下的不同内容，我们只需要根据这些信息即可判断出当前Tomcat的运行模式：

bio

信息: Starting ProtocolHandler [“http-bio-8080”] 2013-8-6 16:17:50 org.apache.coyote.AbstractProtocol start

nio

信息: Starting ProtocolHandler [“http-nio-8080”] 2013-8-6 16:59:53 org.apache.coyote.AbstractProtocol start

apr

信息: Starting ProtocolHandler [“http-apr-8080”] 2013-8-6 17:03:07 org.apache.coyote.AbstractProtocol start

Tomcat 6.x版本从6.0.32开始就默认支持apr。
Tomcat 7.x版本从7.0.30开始就默认支持apr。
因此，如果读者使用的Tomcat版本比较陈旧的话，强烈建议升级到最新的稳定版本。


在tomcat架构分析(概览)中已经介绍过，connector组件是service容器中的一部分。它主要是接收，解析http请求，然后调用本service下的相关servlet。由于tomcat从架构上采用的是一个分层结构，因此根据解析过的http请求，定位到相应的servlet也是一个相对比较复杂的过程。 
 
整个connector实现了从接收socket到调用servlet的全部过程。先来看一下connector的功能逻辑； 

 
 
 
 
  
  接收socket
  
  从socket获取数据包，并解析成HttpServletRequest对象
  
  从engine容器开始走调用流程，经过各层valve，最后调用servlet完成业务逻辑
  
  返回response，关闭socket
 
 

可以看出，整个connector组件是tomcat运行主干，之前介绍的各个模块都是tomcat启动时，静态创建好的，通过connector将这些模块串了起来。 
通常在实际运行中，特别是对于一些互联网应用而言，网络吞吐一直是整个服务的瓶颈所在，因此，connector的运行效率在一定程度上影响了tomcat的整体性能。相对来说，tomcat在处理静态页面方面一直有一些瓶颈，因此通常的服务架构都是前端类似nginx的web服务器，后端挂上tomcat作为应用服务器(当然还有些其他原因，例如负载均衡等)。Tomcat在connector的优化上做了一些特殊的处理，这些都是可选的，通过部署，配置方便完成，例如APR（Apache Portable Runtime），BIO，NIO等。 
目前connector支持的协议是HTTP和AJP。AJP是Apache与其他服务器之间的通信协议。通常在集群环境中，例如前端web服务器和后端应用服务器或servlet容器，使用AJP会比HTTP有更好的性能，这里引述apache官网上的一段话“ If integration with the native webserver is needed for any reason, an AJP connector will provide faster performance than proxied HTTP. AJP clustering is the most efficient from the Tomcat perspective. It is otherwise functionally equivalent to HTTP clustering.” 
本篇主要是针对HTTP协议的connector进行阐述。先来看一下connector的配置，在server.xml里； 

 
 
 
 
  
  
  
   
   
     Xml代码   
    
  
  
  
  
   
   <Connector port="80" URIEncoding="UTF-8" protocol="HTTP/1.1"    
                  connectionTimeout="20000"    
                  redirectPort="7443" />   
  
 
 
 
 

熟悉的80端口不必说了。“protocol”这里是指这个connector支持的协议。针对HTTP协议而言，这个属性可以配置的值有： 

 
 
 
 
  
  HTTP/1.1
  
  org.apache.coyote.http11.Http11Protocol –BIO实现
  
  org.apache.coyote.http11.Http11NioProtocol –NIO实现
  
  定制的接口
 
 

配置“HTTP/1.1”和“org.apache.coyote.http11.Http11Protocol”的效果是一样的，因此connector的HTTP协议实现缺省是支持BIO的。无论是BIO还是NIO都是实现一个org.apache.coyote.ProtocolHandler接口，因此如果需要定制化，也必须实现这个接口。 
本篇就来看看缺省状态下HTTP connector的架构及其消息流。 
 
可以看见connector中三大块 

 
 
 
 
  
  Http11Protocol
  
  Mapper
  
  CoyoteAdapter
 
 

Http11Protocol 
类全路径org.apache.coyote.http11.Http11Protocol，这是支持http的BIO实现。 Http11Protocol包含了JIoEndpoint对象及Http11ConnectionHandler对象。 
Http11ConnectionHandler对象维护了一个Http11Processor对象池，Http11Processor对象会调用CoyoteAdapter完成http request的解析和分派。 
JIoEndpoint维护了两个线程池，Acceptor及Worker。Acceptor是接收socket，然后从Worker线程池中找出空闲的线程处理socket，如果worker线程池没有空闲线程，则Acceptor将阻塞。Worker是典型的线程池实现。Worker线程拿到socket后，就从Http11Processor对象池中获取Http11Processor对象，进一步处理。除了这个比较基础的Worker线程池，也可以通过基于java concurrent 系列的java.util.concurrent.ThreadPoolExecutor线程池实现，不过需要在server.xml中配置相应的节点，即在connector同级别配置<Executor>，配置完后，使用ThreadPoolExecutor与Worker在实现上没有什么大的区别，就不赘述了。 

 
 
 
 
  
  
  
   
   
     Xml代码   
    
  
  
  
  
   
   <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"    
           maxThreads="150" minSpareThreads="4"/>   
  
 
 
 
 

图中的箭头代表了消息流。 
Mapper 
类全路径org.apache.tomcat.util.http.mapper.Mapper，此对象维护了一个从Host到Wrapper的各级容器的快照。它主要是为了，当http request被解析后，能够将http request绑定到相应的servlet进行业务处理。前面的文章中已经说明，在加载各层容器时，会将它们注册到JMX中。 
 
所以当connector组件启动的时候，会从JMX中查询出各层容器，然后再创建这个Mapper对象中的快照。 
CoyoteAdapter 
全路径org.apache.catalina.connector.CoyoteAdapter，此对象负责将http request解析成HttpServletRequest对象，之后绑定相应的容器，然后从engine开始逐层调用valve直至该servlet。在session管理中，已经说明，根据request中的jsessionid绑定服务器端的相应session。这个jsessionid按照优先级或是从request url中获取，或是从cookie中获取，然后再session池中找到相应匹配的session对象，然后将其封装到HttpServletRequest对象。所有这些都是在CoyoteAdapter中完成的。看一下将request解析为HttpServletRequest对象后，开始调用servlet的代码； 

 
 
 
 
  
  
  
   
   
     Java代码   
    
  
  
  
  
   
   connector.getContainer().getPipeline().getFirst().invoke(request, response);   
  
 
 
 
 

connector的容器就是StandardEngine，代码的可读性很强，获取StandardEngine的pipeline，然后从第一个valve开始调用逻辑，相应的过程请参照tomcat架构分析(valve机制)。