打开Tomcat的配置目录，我们会发现下面的配置文件：

这篇博客就来介绍下这几个配置文件的作用，以及常用的配置选项。

server.xml是Tomcat的主配置文件，可以对Service, Connector, Engine, Realm, Valve, Hosts等主组件进行相关配置。

Tomcat的conf目录下面的web.xml配置文件和我们平时应用中WEB-INF下面的配置web.xml功能一致，只是Tomcat下面的这个配置文件用来配置所有应用通用的配置，对所用应用生效。

通常Tomcat下面的这个配置文件不需要我们自己另行做额外配置。

上面的web.xml是Tomcat提供的通用的配置。一般情况下，webApp也都会有自己的web.xml配置，存放在WEB-INF下面，这边也给出一个webApp的配置：

context组件是host组件的子组件。context.xml中的配置是所有host组件的通用配置，Tomcat的conf目录下的context.xml的内容，如下。（通常，这个配置文件也不需要我们做另外的配置）

Tomcat日志相关的配置文件，不是重点。

Tomcat提供了一个管理控制台，在控制台的manager的管理页面，我们能够查看到所有部署的应用的运行状态、也能管理应用的运行。当然，我们也能通过这个界面进行应用部署。

当然，想要通过这个界面进行应用管理和部署，需要用户进行登陆。这些配置就是在tomcat-users.xml中进行配置的。

Tomcat中支持的所有的用户管理角色有：

配置用户的角色、登录名和密码，需要在tomcat-users.xml中进行配置。

如果想要访问manager页面需要配置：

如果需要使用到远程部署等功能，需要添加上：

下面给出一个比较完整的配置列子，生产环境需要根据具体需求配置用户和角色。

关于jaspic-providers.xml配置，作用和tomcat-user.xml类似，都是实现用户认证的。Tomcat 实现了 JASPIC 1.1 Maintenance Release B 标准，并通过这个配置文件集成第三方 JASPIC 身份验证。

但是这个认证方式不怎么使用，大家不用太关注这个配置。

这里面的很多配置是在Tomcat以安全模式启动时才会生效的，平时我们大多情况下都不会以安全模式启动Tomcat，所有很多配置可能用不太到。关于对Java中SecurityManager的介绍，大家可以参考下这边文章，比较浅显易懂。（这边留个问题，是否需要使用安全模式启动Java应用？）

不过catalina.properties中关于公共组件的配置，还是比较有用的，我们可以看下。

catalina.properties中的配置分为四个部分：

第一部分：安全设置

package.access

package.definition

第二部分：类加载设置（可以重点关注下）

common.loader

server.loader

shared.loader

第三部分：不需要扫描的类设置

tomcat.util.scan.DefaultJarScanner.jarsToSkip

org.apache.catalina.startup.ContextConfig.jarsToSkip

org.apache.catalina.startup.TldConfig.jarsToSkip

第四部分：字符缓存设置

tomcat.util.buf.StringCache.byte.enabled tomcat.util.buf.StringCache.char.enabled tomcat.util.buf.StringCache.trainThreshold tomcat.util.buf.StringCache.cacheSize

Tomcat加载类的顺序是：

所以加载完项目的WEB-INF的lib下面的Jar包后回来加载common下面的包。关于common loader，tomcat已经做了相关配置：

上面的配置表示，common loader会加载catalina.base和catalina.home下面的class类和Jar包中的类。

关于server.loader和shared.loader，Tomcat并没有做出明确的配置，我们可以自己进行配置。比如：

上面的含义和common loader的含义一致。

平时我们的一些组件假如需要让所有Web应用依赖的话，我们就可以放在common.loader、server.loader和shared.loader指定的目录下面。

再回顾一下Tomcat处理请求的过程：在accept**队列中接收连接（当客户端向服务器发送请求时，如果客户端与OS完成三次握手建立了连接，则OS将该连接放入accept队列）；在连接中获取请求的数据，生成request；调用servlet容器处理请求；返回response****。**

相对应的，Connector中的几个参数功能如下：

1、acceptCount

accept队列的长度；当accept队列中连接的个数达到acceptCount时，队列满，进来的请求一律被拒绝。默认值是100。

2、maxConnections

Tomcat在任意时刻接收和处理的最大连接数。当Tomcat接收的连接数达到maxConnections时，Acceptor线程不会读取accept队列中的连接；这时accept队列中的线程会一直阻塞着，直到Tomcat接收的连接数小于maxConnections。如果设置为-1，则连接数不受限制。

默认值与连接器使用的协议有关：NIO的默认值是10000，APR/native的默认值是8192，而BIO的默认值为maxThreads（如果配置了Executor，则默认值是Executor的maxThreads）。

在windows下，APR/native的maxConnections值会自动调整为设置值以下最大的1024的整数倍；如设置为2000，则最大值实际是1024。

3、maxThreads

请求处理线程的最大数量。默认值是200（Tomcat7和8都是的）。如果该Connector绑定了Executor，这个值会被忽略，因为该Connector将使用绑定的Executor，而不是内置的线程池来执行任务。

maxThreads规定的是最大的线程数目，并不是实际running的CPU数量；实际上，maxThreads的大小比CPU核心数量要大得多。这是因为，处理请求的线程真正用于计算的时间可能很少，大多数时间可能在阻塞，如等待数据库返回数据、等待硬盘读写数据等。因此，在某一时刻，只有少数的线程真正的在使用物理CPU，大多数线程都在等待；因此线程数远大于物理核心数才是合理的。

换句话说，Tomcat通过使用比CPU核心数量多得多的线程数，可以使CPU忙碌起来，大大提高CPU的利用率。

4、参数设置

（1）maxThreads的设置既与应用的特点有关，也与服务器的CPU核心数量有关。通过前面介绍可以知道，maxThreads数量应该远大于CPU核心数量；而且CPU核心数越大，maxThreads应该越大；应用中CPU越不密集（IO越密集），maxThreads应该越大，以便能够充分利用CPU。当然，maxThreads的值并不是越大越好，如果maxThreads过大，那么CPU会花费大量的时间用于线程的切换，整体效率会降低。

（2）maxConnections的设置与Tomcat的运行模式有关。如果tomcat使用的是BIO，那么maxConnections的值应该与maxThreads一致；如果tomcat使用的是NIO，那么类似于Tomcat的默认值，maxConnections值应该远大于maxThreads。

（3）通过前面的介绍可以知道，虽然tomcat同时可以处理的连接数目是maxConnections，但服务器中可以同时接收的连接数为maxConnections+acceptCount 。acceptCount的设置，与应用在连接过高情况下希望做出什么反应有关系。如果设置过大，后面进入的请求等待时间会很长；如果设置过小，后面进入的请求立马返回connection refused。