Tomcat提供了一个管理控制台，在控制台的manager的管理页面，我们能够查看到所有部署的应用的运行状态、也能管理应用的运行。当然，我们也能通过这个界面进行应用部署。
当然，想要通过这个界面进行应用管理和部署，需要用户进行登陆。这些配置就是在tomcat-users.xml中进行配置的。
Tomcat中支持的所有的用户管理角色有：
Copy<!-- 相当于admin角色,网站管理员角色 --><role rolename="admin-gui"/> <role rolename="admin-script"/><!--允许访问html接口(即URL路径为/manager/html/*)--><role rolename="manager-gui"/><!-- 允许访问纯文本接口(即URL路径为/manager/text/*) --><role rolename="manager-script"/><!-- 允许访问JMX代理接口(即URL路径为/manager/jmxproxy/*)--><role rolename="manager-jmx"/><!-- 允许访问Tomcat只读状态页面(即URL路径为/manager/status/*)--><role rolename="manager-status"/>
配置用户的角色、登录名和密码，需要在tomcat-users.xml中进行配置。
如果想要访问manager页面需要配置：
Copy<role rolename="manager-gui"/><user username="admin" password="password" roles="manager-gui"/>
如果需要使用到远程部署等功能，需要添加上：
Copy<role rolename="manager-script" /><user username="admin" password="password" roles="manager-gui,manager-script"/>
下面给出一个比较完整的配置列子，生产环境需要根据具体需求配置用户和角色。
Copy <!-- 相当于admin角色,网站管理员角色 --> <role rolename="admin-gui"/> <role rolename="admin-script"/> <!--允许访问html接口(即URL路径为/manager/html/*)--> <role rolename="manager-gui"/> <!-- 允许访问纯文本接口(即URL路径为/manager/text/*) --> <role rolename="manager-script"/> <!-- 允许访问JMX代理接口(即URL路径为/manager/jmxproxy/*)--> <role rolename="manager-jmx"/> <!-- 允许访问Tomcat只读状态页面(即URL路径为/manager/status/*)--> <role rolename="manager-status"/> <user username="admin" password="admin123" roles="admin-gui,admin-script"/> <user username="manager" password="manager123" roles="manager-gui,manager-script"/>
jaspic-providers.xml配置#
关于jaspic-providers.xml配置，作用和tomcat-user.xml类似，都是实现用户认证的。Tomcat 实现了 JASPIC 1.1 Maintenance Release B 标准，并通过这个配置文件集成第三方 JASPIC 身份验证。
但是这个认证方式不怎么使用，大家不用太关注这个配置。
catalina.properties和catalina.policy配置#
这里面的很多配置是在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加载类的顺序是：
CopyBootstrap--->System--->/WEB-INF/classes---> /WEB-INF/lib/*.jar---> Common--->Server--->Shared
所以加载完项目的WEB-INF的lib下面的Jar包后回来加载common下面的包。关于common loader，tomcat已经做了相关配置：
Copycommon.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"上面的配置表示，common loader会加载catalina.base和catalina.home下面的class类和Jar包中的类。
关于server.loader和shared.loader，Tomcat并没有做出明确的配置，我们可以自己进行配置。比如：
Copyserver.loader=${catalina.base}/server/classes,${catalina.base}/server/lib/*.jar
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar上面的含义和common loader的含义一致。
平时我们的一些组件假如需要让所有Web应用依赖的话，我们就可以放在common.loader、server.loader和shared.loader指定的目录下面。
关于Connector组件参数的额外说明#
再回顾一下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。
发表评论