Tomcat配置NIO

时间 2019-12-01

标签 tomcat 配置 nio 栏目 Tomcat 繁體版

原文原文链接

tomcat的运行模式有3种.修改他们的运行模式.3种模式的运行是否成功,能够看他的启动控制台,或者启动日志.或者登陆他们的默认页面http://localhost:8080/查看其中的服务器状态。html

1)biojava

默认的模式,性能很是低下,没有通过任何优化处理和支持.web

2)nio 数据库

利用java的异步io护理技术,no blocking IO技术.apache

想运行在该模式下，直接修改server.xml里的Connector节点,修改protocol为编程

 <Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol" 
	connectionTimeout="20000" 
	URIEncoding="UTF-8" 
	useBodyEncodingForURI="true" 
	enableLookups="false" 
	redirectPort="8443" />

启动后,就能够生效。windows

3)apr tomcat

安装起来最困难,可是从操做系统级别来解决异步的IO问题,大幅度的提升性能.服务器

必需要安装apr和native，直接启动就支持apr。下面的修改纯属多余，仅供你们扩充知识,但仍然须要安装apr和native网络

如nio修改模式,修改protocol为org.apache.coyote.http11.Http11AprProtocol

Tomcat 6.X实现了JCP的Servlet 2.5和JSP2.1的规范，而且包括其它不少有用的功能，使它成为开发
和部署web应用和web服务的坚实平台。
       NIO （No-blocking I/O）从JDK 1.4起，NIO API做为一个基于缓冲区，并能提供非阻塞I/O操做的API
被引入。

       做为开源web服务器的java实现，tomcat几乎就是web开发者开发、测试的首选，有不少其余商业服务
器的开发者也会优先选择tomcat做为开发时候使用，而在部署的时候，把应用发布在商业服务器上。也有
许多商业应用部署在tomcat上，tomcat承载着其核心的应用。可是不少开发者很迷惑，为何在本身的应
用里使用tomcat做为平台的时候，而并发用户超过必定数量，服务器就变的很是繁忙，并且很快就出现了
connection refuse的错误。可是不少商业应用部署在tomcat上运行却安然无恙。

      其中有个很大的缘由就是，配置良好的tomcat都会使用APR(Apache Portable Runtime),APR是
Apache HTTP Server2.x的核心，它是高度可移植的本地库，它使用高性能的UXIN I/O操做，低性能的
java io操做，可是APR对不少Java开发者而言可能稍稍有点难度，在不少OS平台上，你可能须要从新编
译APR。可是从Tomcat6.0之后, Java开发者很容易就能够是用NIO的技术来提高tomcat的并发处理能力。
可是为何NIO能够提高tomcat的并发处理能力呢，咱们先来看一下java 传统io与 java NIO的差异。

Java 传统的IO操做都是阻塞式的(blocking I/O), 若是有socket的编程基础，你会接触过堵塞socket和
非堵塞socket，堵塞socket就是在accept、read、write等IO操做的的时候，若是没有可用符合条件的资
源，不立刻返回，一直等待直到有资源为止。而非堵塞socket则是在执行select的时候，当没有资源的时
候堵塞，当有符合资源的时候，返回一个信号，而后程序就能够执行accept、read、write等操做，通常来
说，若是使用堵塞socket，一般咱们一般开一个线程accept socket，当读完此次socket请求的时候，开一
个单独的线程处理这个socket请求；若是使用非堵塞socket，一般是只有一个线程，一开始是select状，
当有信号的时候能够经过能够经过多路复用（Multiplexing)技术传递给一个指定的线程池来处理请求，然
后原来的线程继续select状态。最简单的多路复用技术能够经过java管道(Pipe)来实现。换句话说，若是
客户端的并发请求很大的时候，咱们可使用少于客户端并发请求的线程数来处理这些请求，而这些来不
及当即处理的请求会被阻塞在java管道或者队列里面，等待线程池的处理。请求听起来很复杂，在这个架
构当道的java 世界里，如今已经有不少优秀的NIO的架构方便开发者使用，好比Grizzly,Apache Mina等
等，若是你对如何编写高性能的网络服务器有兴趣，你能够研读这些源代码。

      简单说一下，在web服务器上阻塞IO(BIO)与NIO一个比较重要的不一样是，咱们使用BIO的时候每每会
为每个web请求引入多线程，每一个web请求一个单独的线程，因此并发量一旦上去了，线程数就上去
了，CPU就忙着线程切换，因此BIO不合适高吞吐量、高可伸缩的web服务器；而NIO则是使用单线程(单
个CPU)或者只使用少许的多线程(多CPU)来接受Socket，而由线程池来处理堵塞在pipe或者队列里的请
求.这样的话，只要OS能够接受TCP的链接，web服务器就能够处理该请求。大大提升了web服务器的可
伸缩性。

    咱们来看一下配置，你只须要在server.xml里把 HTTP Connector作以下更改，

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

而后启动服务器，你会看到org.apache.coyote.http11.Http11NioProtocol start的信息，表示NIO已经启动。其余的配置请参考官方配置文档。

Enjoy it.

最后贴上官方文档上对tomcat的三种Connector的方式作一个简单比较，

Java Blocking Connector       Java Nio Blocking Connector       APR Connector

Classname         Http11Protocol                  Http11NioProtocol         Http11AprProtocol

Tomcat Version   3.x 4.x 5.x 6.x                       6.x                     5.5.x 6.x

Support Polling         NO                             YES                        YES

Polling Size           N/A                   Unlimited - Restricted by mem        Unlimited

Read HTTP Request     Blocking                     Blocking                       Blocking

Read HTTP Body        Blocking                     Blocking                       Blocking

Write HTTP Response   Blocking                     Blocking                       Blocking

SSL Support           Java SSL                     Java SSL                       OpenSSL

SSL Handshake         Blocking                     Non blocking                   Blocking

Max Connections       maxThreads                   See polling size               See polling size

若是读者有socket的编程基础，应该会接触过堵塞socket和非堵塞socket，堵塞socket就是在accept、read、write等IO操做的的时候，若是没有可用符合条件的资源，不立刻返回，一直等待直到有资源为止。而非堵塞socket则是在执行select的时候，当没有资源的时候堵塞，当有符合资源的时候，返回一个信号，而后程序就能够执行accept、read、write等操做，这个时候，这些操做是立刻完成，而且立刻返回。而windows的winsock则有所不一样，能够绑定到一个EventHandle里，也能够绑定到一个HWND里，当有资源到达时，发出事件，这时执行的io操做也是立刻完成、立刻返回的。通常来讲，若是使用堵塞socket，一般咱们时开一个线程accept socket，当有socket连接的时候，开一个单独的线程处理这个socket；若是使用非堵塞socket，一般是只有一个线程，一开始是select状态，当有信号的时候立刻处理，而后继续select状态。 
　　 
　　按照大多数人的说法，堵塞socket比非堵塞socket的性能要好。不过也有小部分人并非这样认为的，例如Indy项目（Delphi一个比较出色的网络包），它就是使用多线程＋堵塞socket模式的。另外，堵塞socket比非堵塞socket容易理解，符合通常人的思惟，编程相对比较容易。 　　 　　nio其实也是相似上面的状况。在JDK1.4，sun公司大范围提高Java的性能，其中NIO就是其中一项。Java的IO操做集中在java.io这个包中，是基于流的阻塞API（即BIO，Block IO）。对于大多数应用来讲，这样的API使用很方便，然而，一些对性能要求较高的应用，尤为是服务端应用，每每须要一个更为有效的方式来处理IO。从JDK 1.4起，NIO API做为一个基于缓冲区，并能提供非阻塞O操做的API（即NIO，non-blocking IO）被引入。 　　 　　BIO与NIO一个比较重要的不一样，是咱们使用BIO的时候每每会引入多线程，每一个链接一个单独的线程；而NIO则是使用单线程或者只使用少许的多线程，每一个链接共用一个线程。 　　 　　这个时候，问题就出来了：咱们很是多的java应用是使用ThreadLocal的，例如JSF的FaceContext、Hibernate的session管理、Struts2的Context的管理等等，几乎全部框架都或多或少地应用ThreadLocal。若是存在冲突，那岂不惊天动地？ 　　 　　后来终于在Tomcat6的文档（http://tomcat.apache.org/tomcat-6.0-doc/aio.html）找到答案。根据上面说明，应该Tomcat6应用nio只是用在处理发送、接收信息的时候用到，也就是说，tomcat6仍是传统的多线程Servlet，我画了下面两个图来列出区别： 　　 　　tomcat5：客户端链接到达 -> 传统的SeverSocket.accept接收链接 -> 从线程池取出一个线程 -> 在该线程读取文本而且解析HTTP协议 -> 在该线程生成ServletRequest、ServletResponse，取出请求的Servlet -> 在该线程执行这个Servlet -> 在该线程把ServletResponse的内容发送到客户端链接 -> 关闭链接。 　　 　　我之前理解的使用nio后的tomcat6：客户端链接到达 -> nio接收链接 -> nio使用轮询方式读取文本而且解析HTTP协议（单线程） -> 生成ServletRequest、ServletResponse，取出请求的Servlet -> 直接在本线程执行这个Servlet -> 把ServletResponse的内容发送到客户端链接 -> 关闭链接。 　　 　　实际的tomcat6：客户端链接到达 -> nio接收链接 -> nio使用轮询方式读取文本而且解析HTTP协议（单线程） -> 生成ServletRequest、ServletResponse，取出请求的Servlet -> 从线程池取出线程，并在该线程执行这个Servlet -> 把ServletResponse的内容发送到客户端链接 -> 关闭链接。 　 　　 　　 　　从上图能够看出，BIO与NIO的不一样，也致使进入客户端处理线程的时刻有所不一样：tomcat5在接受链接后立刻进入客户端线程，在客户端线程里解析HTTP协议，而tomcat6则是解析完HTTP协议后才进入多线程，另外，tomcat6也比5早脱离客户端线程的环境。 　　 　　实际的tomcat6与我以前猜测的差异主要集中在如何处理servlet的问题上。实际上即便抛开ThreadLocal的问题，我以前理解tomcat6只使用一个线程处理的想法实际上是行不一样的。你们都有经验：servlet是基于BIO的，执行期间会存在堵塞的，例如读取文件、数据库操做等等。tomcat6使用了nio，但不可能要求servlet里面要使用nio，而一旦存在堵塞，效率天然会锐降。 　　　 　　 　　因此，最终的结论固然是tomcat6的servlet里面，ThreadLocal照样可使用，不存在冲突。

http://www.cnblogs.com/sunwei2012/archive/2010/03/05/1679299.html