Tomcat学习记录

Tomcat是什么？

Tomcat 服务器Apache软件基金会项目中的一个核心项目，是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。

Tomcat的缺省端口是多少，怎么修改

找到Tomcat目录下的conf文件夹

进入conf文件夹里面找到server.xml文件

打开server.xml文件

在server.xml文件里面找到下列信息

把Connector标签的8080端口改成你想要的端口

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

tomcat 有哪几种Connector 运行模式(优化)？

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

BIO：同步并阻塞 一个线程处理一个请求。缺点：并发量高时，线程数较多，浪费资源。

Tomcat7或以下，在Linux系统中默认使用这种方式。

配制项：protocol=”HTTP/1.1”
NIO：同步非阻塞IO 利用Java的异步IO处理，可以通过少量的线程处理大量的请求，可以复用同一个线程处理多个connection(多路复用)。

Tomcat8在Linux系统中默认使用这种方式。

Tomcat7必须修改Connector配置来启动。

配制项：protocol=”org.apache.coyote.http11.Http11NioProtocol”

备注：我们常用的Jetty，Mina，ZooKeeper等都是基于java nio实现.
APR：即Apache Portable Runtime，从操作系统层面解决io阻塞问题。AIO方式，异步非阻塞IO(Java NIO2又叫AIO)

主要与NIO的区别主要是操作系统的底层区别。可以做个比喻：比作快递，NIO就是网购后要自己到官网查下快递是否已经到了(可能是多次)，然后自己去取快递；AIO就是快递员送货上门了(不用关注快递进度)。

配制项：protocol=”org.apache.coyote.http11.Http11AprProtocol”

备注：需在本地服务器安装APR库。Tomcat7或Tomcat8在Win7或以上的系统中启动默认使用这种方式。Linux如果安装了apr和native，Tomcat直接启动就支持apr。

Tomcat有几种部署方式？

在Tomcat中部署Web应用的方式主要有如下几种：

利用Tomcat的自动部署。

把web应用拷贝到webapps目录。Tomcat在启动时会加载目录下的应用，并将编译后的结果放入work目录下。
使用Manager App控制台部署。

在tomcat主页点击“Manager App” 进入应用管理控制台，可以指定一个 web应用的路径或war文件。
修改conf/server.xml文件部署。

修改conf/server.xml文件，增加Context节点可以部署应用。
增加自定义的Web部署文件。

在conf/Catalina/localhost/ 路径下增加 xyz.xml文件，内容是Context节点，可以部署应用

tomcat容器是如何创建servlet类实例？用到了什么原理？

当容器启动时，会读取在webapps目录下所有的web应用中的web.xml 文件，然后对xml文件进行解析，并读取servlet注册信息。然后，将每个应用中注册的servlet类都进行加载，并通过反射的方式实例化。（有时候也是在第一次请求时实例化）
在servlet注册时加上1如果为正数，则在一开始就实例化，如果不写或为负数，则第一次请求实例化。

Tomcat工作模式

Tomcat作为servlet容器，有三种工作模式：

独立的servlet容器，servlet容器是web服务器的一部分；
进程内的servlet容器，servlet容器是作为web服务器的插件和java容器的实现，web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。反应速度快但伸缩性不足；
进程外的servlet容器，servlet容器运行于web服务器之外的地址空间，并作为web服务器的插件和java容器实现的结合。反应时间不如进程内但伸缩性和稳定性比进程内优；进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类：
- Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是 Apache, IIS, Nginx等；
- Tomcat作为独立服务器：请求来自于web浏览器；

面试时问到Tomcat相关问题的几率并不高，正式因为如此，很多人忽略了对 Tomcat相关技能的掌握，下面这一篇文章整理了Tomcat相关的系统架构，介绍了Server、Service、Connector、Container之间的关系，各个模块的功能，可以说把这几个掌握住了，Tomcat相关的面试题你就不会有任何问题了！

另外，在面试的时候你还要有意识无意识的往Tomcat这个地方引，就比如说常见的Spring MVC的执行流程，一个URL的完整调用链路，这些相关的题目你是可以往Tomcat处理请求的这个过程去说的！掌握了Tomcat这些技能，面试官一定会佩服你的！

学了本章之后你应该明白的是：

Server、Service、Connector、Container四大组件之间的关系和联系，以及他们的主要功能点；
Tomcat执行的整体架构，请求是如何被一步步处理的；
Engine、Host、Context、Wrapper相关的概念关系；
Container是如何处理请求的；
Tomcat用到的相关设计模式；

Tomcat顶层架构

俗话说，站在巨人的肩膀上看世界，一般学习的时候也是先总览一下整体，然后逐个部分个个击破，最后形成思路，了解具体细节，Tomcat的结构很复杂，但是 Tomcat 非常的模块化，找到了 Tomcat 最核心的模块，问题才可以游刃而解，了解了 Tomcat 的整体架构对以后深入了解 Tomcat 来说至关重要！先上一张Tomcat的顶层结构图（图A），如下：

Tomcat 作用

Tomcat 是一个能够处理请求并产生响应的应用程序。Tomcat 实现了 JavaEE 平台下的一些技术规范，所以我们可以在 Tomcat 中运行我们所编写的 Servlet、JSP。

Tomcat 运行原理

web服务器：监听请求端口

jsp/servlet容器：engine引擎：拿到请求数据包(请求行，请求头，请求体)后进行解析将其封装为httpServletRequest对象，根据请求行的资源找到对应的jsp/servlet来运行

Tomcat 架构图

默认仅支持HTTP协议

Tomcat 组件

都在其核心配置文件server.xml中

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN"><Service name="Catalina"><!-- 连接器监听端口是 8080，默认通讯协议是HTTP/1.1 --><Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /><!-- 名字为 Catalina 的引擎，其默认的虚拟主机是 localhost --><Engine name="Catalina" defaultHost="localhost"><!-- 名字为 localhost 的虚拟主机，其目录是webapps--><Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"></Host></Engine></Service>
</Server>

Server 组件

Tomcat中最顶层的容器是Server，代表着整个服务器，从上图中可以看出，一个Server可以包含至少一个Service，即可以包含多个Service，用于具体提供服务。

启动一个 server 实例就是一个Tomcat实例（即一个 JVM）单进程指的就是server实例，它监听在 8005 端口以接收 shutdown 命令。Server的定义不能使用同一个端口，这意味着如果在同一个物理机上启动了多个 Server 实例，必须配置它们使用不同的端口。
<Server port="8005" shutdown="SHUTDOWN">// 这样就不会监听8005端口来关闭了 ，这样就只能通过关闭按钮来关闭了
<Server port="-1" shutdown="SHUTDOWN">
port: 接收 shutdown 指令的端口，默认为 8005，会有安全问题；
shutdown：发往此 Server 用于实现关闭 tomcat 实例的命令字符串，默认为 SHUTDOWN；

Service 组件

Service主要包含两个部分：Connector和Container。从上图中可以看出 Tomcat 的心脏就是这两个组件，他们的作用如下：

Connector用于处理连接相关的事情，并提供Socket与Request请求和 Response响应相关的转化;
Container用于封装和管理Servlet，以及具体处理Request请求；

Service 主要用于关联一个引擎和与此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收请求并将其转发至关联的引擎进行处理。困此，Service 要包含一个引擎、一个或多个连接器。
<Service name="Catalina">
name：此服务的名称，默认为 Catalina；

如果配置了多个service表示配置了多个引擎和连接器的关系

一个Tomcat中只有一个Server，一个Server可以包含多个Service，一个 Service只有一个Container，但是可以有多个Connectors，这是因为一个服务可以有多个连接，如同时提供Http和Https链接，也可以提供向相同协议不同端口的连接，示意图如下（Engine、Host、Context下面会说到）：

多个 Connector 和一个 Container 就形成了一个 Service，有了 Service 就可以对外提供服务了，但是 Service 还要一个生存的环境，必须要有人能够给她生命、掌握其生死大权，那就非 Server 莫属了！所以整个 Tomcat 的生命周期由 Server 控制。

另外，上述的包含关系或者说是父子关系，都可以在tomcat的conf目录下的 server.xml配置文件中看出，下图是删除了注释内容之后的一个完整的 server.xml配置文件（Tomcat版本为8.0）

上边的配置文件，还可以通过下边的一张结构图更清楚的理解：

Server标签设置的端口号为8005，shutdown=”SHUTDOWN” ，表示在 8005端口监听“SHUTDOWN”命令，如果接收到了就会关闭Tomcat。一个 Server有一个Service，当然还可以进行配置，一个Service有多个Connector， Service左边的内容都属于Container的，Service下边是Connector。

Tomcat顶层架构小结

Tomcat中只有一个Server，一个Server可以有多个Service，一个 Service可以有多个Connector和一个Container；
Server掌管着整个Tomcat的生死大权；
Service 是对外提供服务的；
Connector用于接受请求并将请求封装成Request和Response来具体处理；
Container用于封装和管理Servlet，以及具体处理request请求；

知道了整个Tomcat顶层的分层架构和各个组件之间的关系以及作用，对于绝大多数的开发人员来说Server和Service对我们来说确实很远，而我们开发中绝大部分进行配置的内容是属于Connector和Container的，所以接下来介绍一下 Connector和Container。

Connector 组件

支持处理不同请求的组件，一个引擎可以有一个或多个连接器，以适应多种请求方式。

默认只开启了处理 Http 协议的连接器。如果需要使用其他协议，需要在 Tomcat 中配置该协议的连接器。

在 Tomcat 中连接器类型通常有 4 种

HTTP 连接器
SSL 连接器
AJP 1.3 连接器
proxy 连接器

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

port：监听的端口

protocol：连接器使用的协议，默认为 HTTP/1.1;

connectionTimeout：等待客户端发送请求的超时时间，单位为毫秒;

redirectPort：如果某连接器支持的协议是 HTTP，当接收客户端发来的 HTTPS 请求时，则转发至此属性定义的端口;

maxThreads：支持的最大并发连接数，默认为 200 个;

Engine 组件

Engine 是 Servlet 处理器的一个实例(就是之前的servlet容器或jsp容器)，即 servlet 引擎，定义在 server.xml 中的 Service 标记中。

Engine 需要 defaultHost 属性来为其定义一个接收所有发往非明确定义虚拟主机的请求的 host 组件。

<Engine name="Catalina" defaultHost="localhost">

name：Engine 组件的名称;

defaultHost：指定一个默认的虚拟主机(host组件)，Tomcat 支持基于 FQDN(Fully Qualified Domain Name全限定域名(可以通过域名的方式来访问tomcat))的虚拟主机，这些虚拟主机可以通过在 Engine 容器中定义多个不同的 Host 组件来实现；但如果此引擎的连接器收到一个发往非非明确定义虚拟主机的请求时则需要将此请求发往一个默认的虚拟主机进行处理，因此，在 Engine 中定义的多个虚拟主机的主机名称中至少要有一个跟defaultHost 定义的主机名称同名；

真正能够处理请求并且运行servlet的是engine组件中的host组件

tomcat会交给哪个host来处理是通过看谁的host的name指定的名字是这个域名，如果找不到用默认的虚拟主机来处理

Engine这个是Servlet的引擎，servlet去处理请求的时候，是根据在defaultHost里配置的这个是默认的虚拟主机，是通过那台电脑去处理这个请求的，默认是localhost，也就是本机，总结为一句话就是，setvlet的请求就是通过这个Engine去处理的。

Host 组件(虚拟主机)

虚拟主机（英语：virtual hosting）或称共享主机（shared web hosting），又称虚拟服务器，是一种在单一主机或主机群上，实现多网域服务的方法，可以运行多个网站或服务的技术。

Host组件位于 Engine 容器中用于接收请求并进行相应处理的虚拟主机(提供了支持某一个种技术运行的平台)。通过该容器可以运行Servlet 或者 JSP 来处理请求。

使用127.0.0.1访问时，engine没有找到对应的host虚拟主机，会交给默认的虚拟主机来处理

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">

name：虚拟主机的名称，Tomcat 通过在请求 URL 中的==域名与 name 中的值匹配，用于查找能够处理该请求的虚拟主机==。如果未找到则交给在 Engine 中 defaultHost 指定的主机处理；

appBase：此 Host 的 webapps 目录，即指定存放 web 应用程序的目录的路径，默认会访问webapps目录下ROOT目录的index.jsp作为首页；

autoDeploy：在 Tomcat 处于运行状态时放置于 appBase 目录中的应用程序文件是否自动进行 deploy部署；默认为 true(是否支持热部署)；

unpackWARs：在启用此 webapps 时是否对 WAR 格式的归档文件先进行展开；默认为true；

Context 组件

默认下是没有这个组件的，默认去查找所有的web资源位置

可以用Context指定除了webapps目录以外的其他目录作为一个web资源

Context 是 Host 的子标签，代表为host组件指定一个 Web 应用，它运行在某个指定的虚拟主机（Host）上；每个 Web 应用都是一个 WAR 文件，或文件的目录；

<Context path="/test" docBase="D:\bjsxt\itbaizhan.war" />

path：context path 既浏览器访问项目的访问路径(在url中输入path)，如果项目在webapps目录下，默认使用项目名字作为context path；如果项目在外部，则需要使用path。

docBase：相应的 Web 应用程序的存放位置；也可以使用相对路径，起始路径为此 Context所属 Host 中 appBase 定义的路径；

Connector和Container的微妙关系

由上述内容我们大致可以知道一个请求发送到Tomcat之后，首先经过Service然后会交给我们的Connector，Connector用于接收请求并将接收的请求封装为 Request和Response来具体处理，Request和Response封装完之后再交由 Container进行处理，Container处理完请求之后再返回给Connector，最后在由Connector通过Socket将处理的结果返回给客户端，这样整个请求的就处理完了！

Connector最底层使用的是Socket来进行连接的，Request和Response是按照 HTTP协议来封装的，所以Connector同时需要实现TCP/IP协议和HTTP协议！

Tomcat既然需要处理请求，那么肯定需要先接收到这个请求，接收请求这个东西我们首先就需要看一下Connector！

Connector架构分析

Connector用于接受请求并将请求封装成Request和Response，然后交给 Container进行处理，Container处理完之后在交给Connector返回给客户端。因此，我们可以把Connector分为四个方面进行理解：

Connector如何接受请求的？
如何将请求封装成Request和Response的？
封装完之后的Request和Response如何交给Container进行处理的？
Container处理完之后如何交给Connector并返回给客户端的？首先看一下Connector的结构图，如下所示：

Connector就是使用ProtocolHandler来处理请求的，不同的ProtocolHandler 代表不同的连接类型，比如：Http11Protocol使用的是普通Socket来连接的， Http11NioProtocol使用的是NioSocket来连接的。

其中ProtocolHandler由包含了三个部件：Endpoint、Processor、Adapter。

Endpoint用来处理底层Socket的网络连接，Processor用于将 Endpoint接收到的Socket封装成Request，Adapter用于将Request交给 Container进行具体的处理。
Endpoint由于是处理底层的Socket网络连接，因此Endpoint是用来实现TCP/IP协议的，而Processor用来实现HTTP协议的，Adapter将请求适配到Servlet容器进行具体的处理。
Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和 AsyncTimeout两个内部类和一个Handler接口。Acceptor用于监听请求，AsyncTimeout用于检查异步Request的超时，Handler用于处理接收到的Socket，在内部调用Processor进行处理。

至此，我们应该很轻松的回答1，2，3的问题了，但是4还是不知道，那么我们就来看一下Container是如何进行处理的以及处理完之后是如何将处理完的结果返回给Connector的？

Container架构分析

Container用于封装和管理Servlet，以及具体处理Request请求，在Container 内部包含了4个子容器，结构图如下：

4个子容器的作用分别是：

Engine：引擎，用来管理多个站点，一个Service最多只能有一个 Engine；
Host：代表一个站点，也可以叫虚拟主机，通过配置Host就可以添加站点；
Context：代表一个应用程序，对应着平时开发的一套程序，或者一个 WEB-INF目录以及下面的web.xml文件；
Wrapper：每一Wrapper封装着一个Servlet；下面找一个Tomcat的文件目录对照一下，如下图所示：

Context和Host的区别是Context表示一个应用，我们的Tomcat中默认的配置下webapps下的每一个文件夹目录都是一个Context，其中ROOT目录中存放着主应用，其他目录存放着子应用，而整个webapps就是一个Host站点。

我们访问应用Context的时候，如果是ROOT下的则直接使用域名就可以访问，例如：www.baidu.com，如果是Host（webapps）下的其他应用，则可以使用www.baidu.com/docs进行访问，当然默认指定的根应用（ROOT）是可以进行设定的，只不过Host站点下默认的主应用是ROOT目录下的。

看到这里我们知道Container是什么，但是还是不知道Container是如何进行请求处理的以及处理完之后是如何将处理完的结果返回给Connector的？别急！下边就开始探讨一下Container是如何进行处理的！

Container如何处理请求的

Container处理请求是使用Pipeline-Valve管道来处理的！（Valve是阀门之意）

Pipeline-Valve是责任链模式，责任链模式是指在一个请求处理的过程中有很多处理者依次对请求进行处理，每个处理者负责做自己相应的处理，处理完之后将处理后的结果返回，再让下一个处理者继续处理。

但是！Pipeline-Valve使用的责任链模式和普通的责任链模式有些不同！区别主要有以下两点：

每个Pipeline都有特定的Valve，而且是在管道的最后一个执行，这个 Valve叫做BaseValve，BaseValve是不可删除的；
在上层容器的管道的BaseValve中会调用下层容器的管道。

我们知道Container包含四个子容器，而这四个子容器对应的BaseValve分别在：StandardEngineValve、StandardHostValve、StandardContextValve、 StandardWrapperValve。

Pipeline的处理流程图如下：

Connector在接收到请求后会首先调用最顶层容器的Pipeline来处理，这里的最顶层容器的Pipeline就是EnginePipeline（Engine的管道）；
在Engine的管道中依次会执行EngineValve1、EngineValve2等等，最后会执行StandardEngineValve，在StandardEngineValve中会调用 Host管道，然后再依次执行Host的HostValve1、HostValve2等，最后在执行StandardHostValve，然后再依次调用Context的管道和Wrapper的管道，最后执行到StandardWrapperValve。
当执行到StandardWrapperValve的时候，会在 StandardWrapperValve中创建FilterChain，并调用其doFilter方法来处理请求，这个FilterChain包含着我们配置的与请求相匹配的Filter和 Servlet，其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet 的service方法，这样请求就得到了处理！
当所有的Pipeline-Valve都执行完之后，并且处理完了具体的请求，这个时候就可以将返回的结果交给Connector了，Connector在通过 Socket的方式将结果返回给客户端。

Tomcat 处理请求过程

用户访问 localhost:8080/test/index.jsp，请求被发送到 Tomcat，被监听 8080 端口并处理 HTTP/1.1 协议的 Connector 获得。
Connector 把该请求交给它所在的 Service 的 Engine 来处理，并等待 Engine 的回应。
Engine 获得请求 localhost/test/index.jsp，匹配所有的虚拟主机 Host。
Engine 匹配到名为 localhost 的 Host 虚拟主机来处理/test/index.jsp 请求（即使匹配不到会请求交给默认 Host 处理），Host 会根据/test 匹配它所拥有的所有的 Context。
匹配到的 Context 获得请求/index.jsp。
tomcat会构造 HttpServletRequest 对象和 HttpServletResponse 对象，作为参数调用 JspServlet的 doGet（）或 doPost（）.执行业务逻辑、数据存储等程序。
Context 把执行完之后的结果通过 HttpServletResponse 对象返回给 Host。
Host 把 HttpServletResponse 返回给 Engine。
Engine 把 HttpServletResponse 对象返回 Connector。
Connector 把 HttpServletResponse 对象返回给客户 Browser。

Tomcat性能优化

衡量系统性能的主要指标：

QPS： Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准；
TPS：系统在给定时间内能够支持的事务数量，单位为TPS（Transactions PerSecond的缩写，也就是事务数/秒，⼀个事务是指⼀个客户机向服务器发送请求然后服务器做出反应的过程。

需要说明的是调优是⼀个过程，并没有明确的参数值可供直接使用，须根据实际生产环境进行调整。从优化的思路上讲，Tomcat优化从以下两方面入手

Tomcat自身配置的优化
JVM虚拟机优化

Tomcat配置调优

以9.0.55版本为例

优化server.xml配置提高性能

调整tomcat线程池

打开tomcat安装目录下的conf目录中的server.xml，Executor元素允许您为一个Service的所有Connector配置一个共享线程池。在运行多个Connector的状况下，这样处理非常有用，而且每个Connector必须设置一个maxThread值，但不要让Tomcat实例并发使用的最大线程数与所有Connector的maxThread的总和一样高。

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

调整tomcat连接器

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

connector连接器参数及含义如下表所示

参数	含义	默认值
accept-count	所有的处理线程都在使用时，传入连接请求的最大队列长度，当队列满时收到的任何请求都将被拒绝	100
max-connections	服务器在任何给定时间接收和处理的最大连接数。当达到这个数字时，服务器将接收一个连接但是不处理。这个附加连接将被阻塞，直到正在处理的连接数降到maxConnections以下，服务器再次开始接收并重新处理新的连接。一旦达到限制，操作系统仍然可以结束基于acceptCount设置的连接数。如果超过max-connections +acceptCount 个连接，新的连接将被拒绝。	10000
max-threads	连接器同一个时刻最大的工作线程数，因此可以确定可以处理的最大并发请求数。	200
min-spare-threads	连接器同一个时刻最少的工作线程数，线程池中保持活跃的的线程最小数量。	10
protocol	表示tomcat使用何种方式来接受和处理client端请求，默认是“HTTP/1.1"。tomcat目前支持：BIO、NIO、NIO2、APR四种IO模型，默认为BIO。对于互联网应用，我们应该在NIO、NIO2之间做选择，因为它能够有效的提升性能（主要是并发能力），其中NIO2即为AIO，需要JDK 1.7+、Linux 2.6+才能支持。	HTTP/1.1

调整 IO 模式

Tomcat8之前的版本默认使用BIO（阻塞式IO），对于每一个请求都要创建一个线程来处理，不适合高并发；Tomcat8以后的版本默认使用NIO模式（非阻塞式IO）

JVM虚拟机优化

虚拟机优化主要有垃圾回收策略优化和内存分配优化

内存模型

Java虚拟机相关参数

参数	含义	优化建议
-server	启动Server，以服务端模式运行	建议开启服务端模式
-Xms	最小堆内存	建议与-Xmx设置相同
-Xmx	最大堆内存	建议设置为可用内存的80%
-XX:MetaspaceSize	元空间初始值
-XX:MaxMetaspaceSize	元空间最大内存	默认无限
-XX:NewRatio	年轻代和老年代大小比值，取值为整数，默认为2	无需修改
-XX:SurvivorRatio	Eden区与Survivor区大小的比值，取值为整数，默认为8	无需修改

参数调整示例

JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"

垃圾收集器

垃圾回收性能指标

吞吐量：工作时间（排除GC时间）占总时间的百分比，工作时间并不仅是程序运行的时间，还包含内存分配时间。
暂停时间：由垃圾回收导致的应用程序停止响应次数/时间。

垃圾收集器分类

串行收集器（Serial Collector）

单线程执行所有的垃圾回收工作，适用于单核CPU服务器
并行收集器（Parallel Collector）

又称为吞吐量收集器（关注吞吐量），以并行的方式执行年轻代的垃圾回收，该方式可以显著降低垃圾回收的开销(指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态)。适用于多处理器或多线程硬件上运行的数据量较大的应用
并发收集器（Concurrent Collector）

以并发的方式执行大部分垃圾回收工作，以缩短垃圾回收的暂停时间。适用于那些响应时间优先于吞吐量的应用，因为该收集器虽然最小化了暂停时间(指用户线程与垃圾收集线程同时执行，但不⼀定是并行的，可能会交替进行)，但是会降低应用程序的性能
CMS收集器（Concurrent Mark Sweep Collector）

并发标记清除收集器，适用于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应用
G1收集器（Garbage-First Garbage Collector）

适用于大容量内存的多核服务器，可以在满足垃圾回收暂停时间目标的同时，以最大可能性实现高吞吐量(JDK1.7之后)

参数	作用
-XX:+UseSerialGC	启用串行收集器
-XX:+UseParallelGC	启用并行垃圾收集器，配置了该选项，那么默认启用 -XX:+UseParallelOldGC
-XX:+UseParNewGC	年轻代采用并行收集器，如果设置了 -XX:+UseConcMarkSweepGC选项，自动启用
-XX:ParallelGCThreads	年轻代及老年代垃圾回收使用的线程数。默认值依赖于JVM使用的CPU个数
-XX:+UseConcMarkSweepGC（CMS）	对于老年代，启用CMS垃圾收集器。当并行收集器无法满足应用的延迟需求时，推荐使用CMS或G1收集器。启用该选项后， -XX:+UseParNewGC自动启用。
-XX:+UseG1GC	启用G1收集器。 G1是服务器类型的收集器，用于多核、大内存的机器。它在保持高吞吐量的情况下，高概率满足GC暂停时间的目标。

在bin/catalina.sh的脚本中 , 追加如下配置 :

JAVA_OPTS="-XX:+UseConcMarkSweepGC"

使用jdk工具查看内存

windows下查看tomcat堆内存

以jdk1.8为例

step1：把C:\Program Files (x86)\Java\jdk1.8.0_291\jre\bin目录下的sawindbg.dll，拷贝到C:\Program Files
(x86)\Java\jre1.8.0_291\bin目录下