Tomcat组件
- 概述:核心组件：Connector 和 Container（以夫妻为例介绍）。多个 Connector 和一个 Container 就形成了一个 Service。Service 只是在 Connector 和 Container 外面多包一层，把它们组装在一起，向外面提供服务，一个 Service 可以设置多个 Connector，但是只能有一个 Container 容器。
注：整个 Tomcat 的生命周期（通过实现Lifecycle实现）由 Server 控制，作用就是要能够提供一个接口让其它程序能够访问到这个 Service 集合、同时要维护它所包含的所有 Service 的生命周期，包括如何初始化、如何结束服务、如何找到别人要访问的 Service。
- 其他重要组件：安全组件 security、logger 日志组件、session、mbeans、naming 等。这些组件共同为 Connector 和 Container 提供必要的服务。
- Connector：
负责接收浏览器的发过来的 tcp 连接请求，创建一个 Request 和 Response 对象分别用于和请求端交换数据，然后从线程池中取出一个线程来处理这个请求，并把产生的 Request 和 Response 对象传给处理这个请求的线程。Connector有三种IO处理模型BIO、NIO、AIO（APR）
注：启动过程：初始化SeverSocket, 初始化线程池，构建Request 和 Response，请求到来时，激活线程，解析http协议，把头写到Request 和 Response中，传给Container,完成之后返回Request 和 Response对象，关闭当前Socket,回收线程。
BIO、NIO、AIO适用场景分析:
BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。
NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。
- Container：
Container 是容器的父接口，所有子容器都必须实现这个接口，Container 容器的设计用的是典型的责任链的设计模式，它有四个子容器组件构成，分别是：Engine、Host、Context、Wrapper，这四个组件不是平行的，而是父子关系，Engine 包含 Host,Host 包含 Context，Context 包含 Wrapper。（子容器的路由放在request中）
Wrapper 代表一个 Servlet，它负责管理一个 Servlet，包括的 Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器，Context是 Servlet 运行的基本环境，对应Web工程，定义在父容器 Host 中，Host 不是必须的，但是要运行 war 程序，就必须要 Host，因为 war 中必有 web.xml 文件，这个文件的解析需要 Host ，如果要有多个 Host 就要定义一个 top 容器 Engine 了。而 Engine 没有父容器了，一个 Engine 代表一个完整的 Servlet 引擎。
4个子容器的作用分别是：
（1）Engine：引擎，用来管理多个站点，一个Service最多只能有一个Engine；
（2）Host：代表一个站点，也可以叫虚拟主机，通过配置Host就可以添加站点；
（3）Context：代表一个应用程序，对应着平时开发的一套程序，或者一个WEB-INF目录以及下面的web.xml文件；
（4）Wrapper：每一Wrapper封装着一个Servlet；
下面找一个Tomcat的文件目录对照一下，如下图所示：
Context和Host的区别是Context表示一个应用，我们的Tomcat中默认的配置下webapps下的每一个文件夹目录都是一个Context，其中ROOT目录中存放着主应用，其他目录存放着子应用，而整个webapps就是一个Host站点。
- 责任链模式：很多对象由每个对象对其下家的引用连接起来形成，请求在链上传递，这样可以不影响客户端而能够在链上增加任意处理节点。包含抽象处理者和具体处理者，整个容器就是通过一个链连接在一起，这个链一直将请求正确传递给最终处理的Servlet。（其中Pipeline和Value扩展了链的功能，使得可以接收外界干预）。
注：此外，还有命令模式，观察者模式，门面模式等
请求处理流程
描述：
- 用户点击网页内容，请求被发送到本机端口8080，被在那里监听的Coyote HTTP/1.1 Connector获得。
- Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应。
- Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host。
- Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机），名为localhost的Host获得请求/test/index.jsp，匹配它所拥有的所有的Context。Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为“ ”的Context去处理）。
- path=“/test”的Context获得请求/index.jsp，在它的mapping table中寻找出对应的Servlet。Context匹配到URL PATTERN为*.jsp的Servlet,对应于JspServlet类。
- 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet（）或doPost（）.执行业务逻辑、数据存储等程序。
- Context把执行完之后的HttpServletResponse对象返回给Host。
- Host把HttpServletResponse对象返回给Engine。
- Engine把HttpServletResponse对象返回Connector。
- Connector把HttpServletResponse对象返回给客户Browser。
调优：
Tomcat在各位JavaWeb从业者常常就是默认的开发环境，但是Tomcat的默认配置作为生产环境，尤其是内存和线程的配置，默认都很低，容易成为性能瓶颈.
幸好Tomcat还有很多的提升空间.下文介绍一下Tomcat优化,可以分为内存,线程,IO.
一:Tomcat内存优化,启动时告诉JVM我要一块大内存(调优内存是最直接的方式)
Windows 下的catalina.bat
Linux 下的catalina.sh 如:
JAVA_OPTS='-Xms256m -Xmx512m'
-Xms<size> JVM初始化堆的大小
-Xmx<size> JVM堆的最大值 实际参数大小根据服务器配置或者项目具体设置.
解决内存泄漏：
能表现不佳的另一个主要原因是内存泄漏，正如我之前说过：始终使用最新的tomcat服务器以获得更好的性能和可伸缩性。现在，这句话变成真的。如果我们使用最新的tomcat版本6.0.26及以上就可以解决这个错误，因为它包含了一个监听器来处理JRE和PermGen的内存泄漏。使用的监听器是，
Java代码
- <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
你可以在server.xml文件中找到这个监听器的配置，server.xml位置在“tomcat project folder/conf/server.xml”。接下来，我们将看看如何调整连接属性“maxThreads”。
二:Tomcat 线程优化 在server.xml中 如:
<Connector port="80" protocol="HTTP/1.1" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700" connectionTimeout="20000" />
maxThreads="X" 表示最多同时处理X个连接
minSpareThreads="X" 初始化X个连接
maxSpareThreads="X" 表示如果最多可以有X个线程，一旦超过X个,则会关闭不在需要的线程
acceptCount="X" 当同时连接的人数达到maxThreads时,还可以排队,队列大小为X.超过X就不处理
maxThreads值设定为“250”，这指定可以由服务器处理的并发请求的最大数量。如果没有指定，这个属性的默认值为“200”。任何多出的并发请求将收到“拒绝连接”的错误提示，直到另一个处理请求进程被释放。
三:Tomcat IO优化
1:同步阻塞IO（JAVA BIO） 同步并阻塞，服务器实现模式为一个连接一个线程(one connection one thread 想想都觉得恐怖,线程可是非常宝贵的资源)，当然可以通过线程池机制改善.
2:JAVA NIO:又分为同步非阻塞IO,异步阻塞IO 与BIO最大的区别one request one thread.可以复用同一个线程处理多个connection(多路复用).
3:,异步非阻塞IO(Java NIO2又叫AIO) 主要与NIO的区别主要是操作系统的底层区别.可以做个比喻:比作快递，NIO就是网购后要自己到官网查下快递是否已经到了(可能是多次)，然后自己去取快递；AIO就是快递员送货上门了(不用关注快递进度)。
BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解.
NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持.
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持.
在server.xml中
<Connector port="80" protocol="org.apache.coyot=-7p11.Http11NioProtocol" - connectionTimeout="20000" URIEncoding="UTF-8" useBodyEncodingForURI="true" enableLookups="false" redirectPort="8443" />
实现对Tomcat的IO切换.
四:大杀器APR
APR是从操作系统级别来解决异步的IO问题,大幅度的提高性能. (http://apr.apache.org/).
APR(Apache Portable Runtime)是一个高可移植库,它是Apache HTTP Server 2.x的核心.能更好地和其它本地web技术集成，总体上让Java更有效率作为一个高性能web服务器平台而不是简单作为后台容器.
在产品环境中，特别是直接使用Tomcat做WEB服务器的时候，应该使用Tomcat Native来提高其性能.如果不配APR，基本上300个线程狠快就会用满，以后的请求就只好等待.但是配上APR之后，并发的线程数量明显下降，从原来的300可能会马上下降到只有几十，新的请求会毫无阻塞的进来.
在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输.如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的.
安装Apache Tomcat Native Library，直接启动就支持apr(http://tomcat.apache.org/native-doc/)它本身是基于APR的. 具体安装方法可以参考其他博客和文章. 排除代码问题Tomcat优化到这个层次,可以应对大部分性能需求.
最后一句话"再牛B的服务器,也顶不住一个傻B的代码".优化的前提条件是良好的代码质量和设计.
五:压缩
Tomcat有一个通过在server.xml配置文件中设置压缩的选项。压缩可以在connector像如下设置中完成，
Java代码
- <Connector port="8080"protocol="HTTP/1.1"*
- connectionTimeout="20000"
- redirectPort="8181"compression="500"
- compressableMimeType="text/html,text/xml,text/plain,application/octet-stream"/>
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8181" compression="500" compressableMimeType="text/html,text/xml,text/plain,application/octet-stream" />
在前面的配置中，当文件的大小大于等于500bytes时才会压缩。如果当文件达到了大小但是却没有被压缩，那么设置属性compression="on"。否则Tomcat默认设置是“off”。接下来我们将看看如何调优数据库。