> 文档中心 > Apache Tomcat Web应⽤服务器,看这一篇就够了

Apache Tomcat Web应⽤服务器,看这一篇就够了


Tomcat 系统架构与原理剖析

浏览器访问服务器的流程

  • http请求的处理过程
    在这里插入图片描述
    注意:浏览器访问服务器使⽤的是Http协议,Http是应⽤层协议,⽤于定义数据通信的格式,具体的数据传输使⽤的是TCP/IP协议

Tomcat 系统总体架构

Tomcat 请求处理⼤致过程

Tomcat是⼀个Http服务器(能够接收并且处理http请求,所以tomcat是⼀个http服务器)
在这里插入图片描述
HTTP 服务器接收到请求之后把请求交给Servlet容器来处理,Servlet 容器通过Servlet接⼝调⽤业务类。Servlet接⼝和Servlet容器这⼀整套内容叫作Servlet规范。
注意:Tomcat既按照Servlet规范的要求去实现了Servlet容器,同时它也具有HTTP服务器的功能。
Tomcat的两个重要身份

  • http服务器
  • Tomcat是⼀个Servlet容器

Tomcat Servlet容器处理流程

在这里插入图片描述
当⽤户请求某个URL资源时

  • 1)HTTP服务器会把请求信息使⽤ServletRequest对象封装起来
  • 2)进⼀步去调⽤Servlet容器中某个具体的Servlet
  • 3)在 2)中,Servlet容器拿到请求后,根据URL和Servlet的映射关系,找到相应的Servlet
  • 4)如果Servlet还没有被加载,就⽤反射机制创建这个Servlet,并调⽤Servlet的init⽅法来完成初始化
  • 5)接着调⽤这个具体Servlet的service⽅法来处理请求,请求处理结果使⽤ServletResponse对象封装
  • 6)把ServletResponse对象返回给HTTP服务器,HTTP服务器会把响应发送给客户端

Tomcat 系统总体架构

Tomcat有两个⾮常重要的功能需要完成

  • 1)和客户端浏览器进⾏交互,进⾏socket通信,将字节流和Request/Response等对象进⾏转换
  • 2)Servlet容器处理业务逻辑

在这里插入图片描述
Tomcat 设计了两个核⼼组件**连接器(Connector)和容器(Container)**来完成 Tomcat 的两⼤核⼼功能。

  • 连接器,负责对外交流: 处理Socket连接,负责⽹络字节流与Request和Response对象的转化;
  • 容器,负责内部处理:加载和管理Servlet,以及具体处理Request请求;

Tomcat 连接器组件 Coyote

Coyote 简介

Coyote 是Tomcat 中连接器的组件名称 , 是对外的接⼝。客户端通过Coyote与服务器建⽴连接、发送请求并接受响应 。

  1. Coyote 封装了底层的⽹络通信(Socket 请求及响应处理)
  2. Coyote 使Catalina 容器(容器组件)与具体的请求协议及IO操作⽅式完全解耦
  3. Coyote 将Socket 输⼊转换封装为 Request 对象,进⼀步封装后交由Catalina 容器进⾏处理,处理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流
  4. Coyote 负责的是具体协议(应⽤层)和IO(传输层)相关内容
    在这里插入图片描述
    Tomcat Coyote ⽀持的 IO模型与协议
    Tomcat⽀持多种应⽤层协议和I/O模型,如下
    在这里插入图片描述
    在 8.0 之前 ,Tomcat 默认采⽤的I/O⽅式为 BIO,之后改为 NIO。 ⽆论 NIO、NIO2 还是 APR, 在性能⽅⾯均优于以往的BIO。 如果采⽤APR, 甚⾄可以达到 Apache HTTP Server 的影响性能。

Coyote 的内部组件及流程

在这里插入图片描述
Coyote 组件及作⽤
在这里插入图片描述

组件 作⽤描述
EndPoint EndPoint 是 Coyote 通信端点,即通信监听的接⼝,是具体Socket接收和发送处理器,是对传输层的抽象,因此EndPoint⽤来实现TCP/IP协议的
Processor Processor 是Coyote 协议处理接⼝ ,如果说EndPoint是⽤来实现TCP/IP协议的,那么Processor⽤来实现HTTP协议,Processor接收来⾃EndPoint的Socket,读取字节流解析成Tomcat Request和Response对象,并通过Adapter将其提交到容器处理,Processor是对应⽤层协议的抽象
ProtocolHandler Coyote 协议接⼝, 通过Endpoint 和 Processor , 实现针对具体协议的处理能⼒。Tomcat 按照协议和I/O 提供了6个实现类 : AjpNioProtocol ,AjpAprProtocol, AjpNio2Protocol , Http11NioProtocol ,Http11Nio2Protocol ,Http11AprProtocol
Adapter 由于协议不同,客户端发过来的请求信息也不尽相同,Tomcat定义了⾃⼰的Request类来封装这些请求信息。ProtocolHandler接⼝负责解析请求并⽣成Tomcat Request类。但是这个Request对象不是标准的ServletRequest,不能⽤Tomcat Request作为参数来调⽤容器。Tomcat设计者的解决⽅案是引⼊CoyoteAdapter,这是适配器模式的经典运⽤,连接器调⽤CoyoteAdapter的Sevice⽅法,传⼊的是Tomcat Request对象,CoyoteAdapter负责将Tomcat Request转成ServletRequest,再调⽤容器

Tomcat Servlet 容器 Catalina

Tomcat 模块分层结构图及Catalina位置

Tomcat是⼀个由⼀系列可配置(conf/server.xml)的组件构成的Web容器,⽽Catalina是Tomcat的servlet容器。
在这里插入图片描述

从另⼀个⻆度来说,Tomcat 本质上就是⼀款 Servlet 容器, 因为 Catalina 才是 Tomcat 的核⼼ , 其他模块都是为Catalina 提供⽀撑的。 ⽐如 : 通过 Coyote 模块提供链接通信,Jasper 模块提供 JSP 引擎,Naming 提供JNDI 服务,Juli 提供⽇志服务。

Servlet 容器 Catalina 的结构

在这里插入图片描述
可以认为整个Tomcat就是⼀个Catalina实例,Tomcat 启动的时候会初始化这个实例,Catalina
实例通过加载server.xml完成其他实例的创建,创建并管理⼀个Server,Server创建并管理多个服务,每个服务⼜可以有多个Connector和⼀个Container。

  • Catalina
    负责解析Tomcat的配置⽂件(server.xml) , 以此来创建服务器Server组件并进⾏管理
  • Server
    服务器表示整个Catalina Servlet容器以及其它组件,负责组装并启动Servlaet引擎,Tomcat连接器。Server通过实现Lifecycle接⼝,提供了⼀种优雅的启动和关闭整个系统的⽅式
  • Service
    服务是Server内部的组件,⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个Container
  • Container
    容器,负责处理⽤户的servlet请求,并返回对象给web⽤户的模块

Container 组件的具体结构

Container组件下有⼏种具体的组件,分别是Engine、Host、Context和Wrapper。这4种组件(容器)是⽗⼦关系。Tomcat通过⼀种分层的架构,使得Servlet容器具有很好的灵活性。

  • Engine
    表示整个Catalina的Servlet引擎,⽤来管理多个虚拟站点,⼀个Service最多只能有⼀个Engine,但是⼀个引擎可包含多个Host
  • Host
    代表⼀个虚拟主机,或者说⼀个站点,可以给Tomcat配置多个虚拟主机地址,⽽⼀个虚拟主机下可包含多个Context
  • Context
    表示⼀个Web应⽤程序, ⼀个Web应⽤可包含多个Wrapper
  • Wrapper
    表示⼀个Servlet,Wrapper 作为容器中的最底层,不能包含⼦容器

上述组件的配置其实就体现在conf/server.xml中。

Tomcat 服务器核⼼配置详解

问题⼀:去哪⼉配置?

  • 核⼼配置在tomcat⽬录下conf/server.xml⽂件

问题⼆:怎么配置?

  • Tomcat 作为服务器的配置,主要是 server.xml ⽂件的配置;
  • server.xml中包含了 Servlet容器的相关配置,即 Catalina 的配置;
  • Xml ⽂件的讲解主要是标签的使⽤

主要标签结构如下:

<Server><Listener/><GlobalNamingResources/><Service/></Server>
  • Server 标签

    <Server port="8005" shutdown="SHUTDOWN"><Listener className="org.apache.catalina.startup.VersionLoggerListener" /><!-- Security listener. Documentation at /docs/config/listeners.html--><Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /><ListenerclassName="org.apache.catalina.core.JreMemoryLeakPreventionListener" /><Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /><Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /><GlobalNamingResources><Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /></GlobalNamingResources><Service name="Catalina"> ...</Service></Server>
  • Service 标签

    <Service name="Catalina">...</Service>
  • Executor 标签

    <!--默认情况下,Service 并未添加共享线程池配置。 如果我们想添加⼀个线程池, 可以在 下添加如下配置:name:线程池名称,⽤于 Connector中指定namePrefix:所创建的每个线程的名称前缀,⼀个单独的线程名称为 namePrefix+threadNumbermaxThreads:池中最⼤线程数minSpareThreads:活跃线程数,也就是核⼼池线程数,这些线程不会被销毁,会⼀直存在maxIdleTime:线程空闲时间,超过该时间后,空闲线程会被销毁,默认值为6000(1分钟),单位 毫秒maxQueueSize:在被执⾏前最⼤线程排队数⽬,默认为Int的最⼤值,也就是⼴义的⽆限。除⾮特 殊情况,这个值 不需要更改,否则会有请求不会被处理的情况发⽣prestartminSpareThreads:启动线程池时是否启动 minSpareThreads部分线程。默认值为 false,即不启动threadPriority:线程池中线程优先级,默认值为5,值从1到10className:线程池实现类,未指定情况下,默认实现类为 org.apache.catalina.core.StandardThreadExecutor。如果想使⽤⾃定义线程池⾸先需要实现 org.apache.catalina.Executor接⼝--><Executor name="commonThreadPool"namePrefix="thread-exec-"maxThreads="200"minSpareThreads="100"maxIdleTime="60000"maxQueueSize="Integer.MAX_VALUE"prestartminSpareThreads="false"threadPriority="5"className="org.apache.catalina.core.StandardThreadExecutor"/>
  • Connector 标签
    Connector 标签⽤于创建链接器实例
    默认情况下,server.xml 配置了两个链接器,⼀个⽀持HTTP协议,⼀个⽀持AJP协议
    ⼤多数情况下,我们并不需要新增链接器配置,只是根据需要对已有链接器进⾏优化

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

    可以使⽤共享线程池

    <Connector port="8080"protocol="HTTP/1.1"executor="commonThreadPool"maxThreads="1000"minSpareThreads="100"acceptCount="1000"maxConnections="1000"connectionTimeout="20000"compression="on"compressionMinSize="2048"disableUploadTimeout="true"redirectPort="8443"URIEncoding="UTF-8" />
  • Engine 标签
    Engine 表示 Servlet 引擎

    <Engine name="Catalina" defaultHost="localhost">...</Engine>
  • Host 标签
    Host 标签⽤于配置⼀个虚拟主机

    <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> ...</Host>
  • Context 标签
    Context 标签⽤于配置⼀个Web应⽤,如下:

    <Host name="www.abc.com" appBase="webapps" unpackWARs="true"autoDeploy="true"><Context docBase="/Users/yingdian/web_demo" path="/web3"></Context> <Valve className="org.apache.catalina.valves.AccessLogValve"directory="logs"prefix="localhost_access_log" suffix=".txt"pattern="%h %l %u %t "%r" %s %b" /></Host>

Tomcat 源码构建及核⼼流程源码剖析

源码构建

下载源码

在这里插入图片描述

源码导⼊IDE之前准备⼯作

  • 解压 tar.gz 压缩包,得到⽬录 apache-tomcat-8.5.50-src

  • 进⼊ apache-tomcat-8.5.50-src ⽬录,创建⼀个pom.xml⽂件,⽂件内容如下

    <project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.apache.tomcat</groupId> <artifactId>apache-tomcat-8.5.50-src</artifactId> <name>Tomcat8.5</name> <version>8.5</version> <build><finalName>Tomcat8.5</finalName><sourceDirectory>java</sourceDirectory> <resources> <resource> <directory>java</directory></resource></resources> <plugins><plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.1</version> <configuration> <encoding>UTF-8</encoding> <source>11</source> <target>11</target></configuration></plugin></plugins></build><dependencies> <dependency> <groupId>org.easymock</groupId> <artifactId>easymock</artifactId> <version>3.4</version></dependency> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId><version>1.7.0</version></dependency> <dependency> <groupId>wsdl4j</groupId> <artifactId>wsdl4j</artifactId> <version>1.6.2</version></dependency> <dependency> <groupId>javax.xml</groupId> <artifactId>jaxrpc</artifactId> <version>1.1</version></dependency> <dependency> <groupId>org.eclipse.jdt.core.compiler</groupId> <artifactId>ecj</artifactId> <version>4.5.1</version></dependency> <dependency> <groupId>javax.xml.soap</groupId> <artifactId>javax.xml.soap-api</artifactId> <version>1.4.0</version></dependency></dependencies></project>
  • 在 apache-tomcat-8.5.50-src ⽬录中创建 source ⽂件夹

  • 将 conf、webapps ⽬录移动到刚刚创建的 source ⽂件夹中

导⼊源码⼯程到IDE并进⾏配置

  • 将源码⼯程导⼊到 IDEA 中

  • 给 tomcat 的源码程序启动类 Bootstrap 配置 VM 参数,因为 tomcat 源码运⾏也需要加载配置⽂件等。

    -Dcatalina.home=/Users/leo/workspace/servers/apache-tomcat-8.5.50-src/source-Dcatalina.base=/Users/leo/workspace/servers/apache-tomcat-8.5.50-src/source-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager-Djava.util.logging.config.file=/Users/yingdian/workspace/servers/apachetomcat-8.5.50-src/source/conf/logging.properties

    在这里插入图片描述

  • 运⾏ Bootstrap 类的 main 函数,此时就启动了tomcat,启动时候会去加载所配置的 conf ⽬录下的server.xml等配置⽂件,所以访问8080端⼝即可,但此时我们会遇到如下的⼀个错误
    在这里插入图片描述
    原因是Jsp引擎Jasper没有被初始化,从⽽⽆法编译JSP,我们需要在tomcat的源码ContextConfig类中的configureStart⽅法中增加⼀⾏代码将 Jsp 引擎初始化,如下
    在这里插入图片描述

  • 重启 Tomcat,正常访问即可。⾄此,Tomcat 源码构建完毕。

核⼼流程源码剖析

Tomcat中的各容器组件都会涉及创建、销毁等,因此设计了⽣命周期接⼝Lifecycle进⾏统⼀规范,各容器组件实现该接⼝。

  • Lifecycle⽣命周期接⼝主要⽅法示意 在这里插入图片描述
  • Lifecycle⽣命周期接⼝继承体系示意
    在这里插入图片描述

核⼼流程源码剖析

源码追踪部分我们关注两个流程:Tomcat启动流程和Tomcat请求处理流程

  • Tomcat启动流程
    在这里插入图片描述

  • Tomcat请求处理流程

    • 请求处理流程分析
      在这里插入图片描述

    • 请求处理流程示意图
      在这里插入图片描述

    • Mapper组件体系结构
      在这里插入图片描述

Tomcat 类加载机制剖析

Java类(.java)—> 字节码⽂件(.class) —> 字节码⽂件需要被加载到jvm内存当中(这个过程就是⼀个类加载的过程)
类加载器(ClassLoader,说⽩了也是⼀个类,jvm启动的时候先把类加载器读取到内存当中去,其他的类(⽐如各种jar中的字节码⽂件,⾃⼰开发的代码编译之后的.class⽂件等等))
要说 Tomcat 的类加载机制,⾸先需要来看看 Jvm 的类加载机制,因为 Tomcat 类加载机制是在 Jvm 类加载机制基础之上进⾏了⼀些变动。

JVM 的类加载机制

JVM 的类加载机制中有⼀个⾮常重要的⻆⾊叫做类加载器(ClassLoader),类加载器有⾃⼰的体系,Jvm内置了⼏种类加载器,包括:引导类加载器、扩展类加载器、系统类加载器,他们之间形成⽗⼦关系,通过 Parent 属性来定义这种关系,最终可以形成树形结构。
在这里插入图片描述

类加载器 作⽤
引导启动类加载器 BootstrapClassLoader c++编写,加载java核⼼库 java.*,⽐如rt.jar中的类,构造ExtClassLoader和AppClassLoader
扩展类加载器 ExtClassLoader java编写,加载扩展库 JAVA_HOME/lib/ext⽬录下的jar中的类,如classpath中的jre ,javax.*或者java.ext.dir指定位置中的类
系统类加载器 SystemClassLoader/AppClassLoader默认的类加载器,搜索环境变量 classpath 中指明的路径

另外:⽤户可以⾃定义类加载器(Java编写,⽤户⾃定义的类加载器,可加载指定路径的 class ⽂件)
  当 JVM 运⾏过程中,⽤户⾃定义了类加载器去加载某些类时,会按照下⾯的步骤(⽗类委托机制)

  1. ⽤户⾃⼰的类加载器,把加载请求传给⽗加载器,⽗加载器再传给其⽗加载器,⼀直到加载器 树的顶层
  2. 最顶层的类加载器⾸先针对其特定的位置加载,如果加载不到就转交给⼦类
  3. 如果⼀直到底层的类加载都没有加载到,那么就会抛出异常 ClassNotFoundException

因此,按照这个过程可以想到,如果同样在 classpath指定的⽬录中和⾃⼰⼯作⽬录中存放相同的 class,会优先加载 classpath ⽬录中的⽂件

双亲委派机制

什么是双亲委派机制

当某个类加载器需要加载某个.class⽂件时,它⾸先把这个任务委托给他的上级类加载器,递归这个操作,如果上级的类加载器没有加载,⾃⼰才会去加载这个类

双亲委派机制的作⽤

  • 防⽌重复加载同⼀个.class。通过委托去向上⾯问⼀问,加载过了,就不⽤再加载⼀遍。
  • 保证数据安全。保证核⼼.class不能被篡改。通过委托⽅式,不会去篡改核⼼.class,即使篡改也不会去加载,即使加载也不会是同⼀个.class对象了。不同的加载器加载同⼀个.class也不是同⼀个.class对象。这样保证了class执⾏安全(如果⼦类加载器先加载,那么我们可以写⼀些与java.lang包中基础类同名的类, 然后再定义⼀个⼦类加载器,这样整个应⽤使⽤的基础类就都变成我们⾃⼰定义的类了。)

Object类 -----> ⾃定义类加载器(会出现问题的,那么真正的Object类就可能被篡改了)

Tomcat 的类加载机制

Tomcat 的类加载机制相对于 Jvm 的类加载机制做了⼀些改变。
没有严格的遵从双亲委派机制,也可以说打破了双亲委派机制
⽐如:有⼀个tomcat,webapps下部署了两个应⽤
app1/lib/a-1.0.jar com.learn.edu.Abc
app2/lib/a-2.0.jar com.learn.edu.Abc
不同版本中Abc类的内容是不同的,代码是不⼀样的

在这里插入图片描述

  • 引导类加载器 和 扩展类加载器 的作⽤不变
  • 系统类加载器正常情况下加载的是 CLASSPATH 下的类,但是 Tomcat 的启动脚本并未使⽤该变量,⽽是加载tomcat启动的类,⽐如bootstrap.jar,通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下
  • Common 通⽤类加载器加载Tomcat使⽤以及应⽤通⽤的⼀些类,位于CATALINA_HOME/lib下,⽐如servlet-api.jar
  • Catalina ClassLoader ⽤于加载服务器内部可⻅类,这些类应⽤程序不能访问
  • Shared ClassLoader ⽤于加载应⽤程序共享类,这些类服务器不会依赖
  • Webapp ClassLoader,每个应⽤程序都会有⼀个独⼀⽆⼆的Webapp ClassLoader,他⽤来加载
  • 本应⽤程序 /WEB-INF/classes 和 /WEB-INF/lib 下的类。
    tomcat 8.5 默认改变了严格的双亲委派机制
    • ⾸先从 Bootstrap Classloader加载指定的类
    • 如果未加载到,则从 /WEB-INF/classes加载
    • 如果未加载到,则从 /WEB-INF/lib/*.jar 加载
    • 如果未加载到,则依次从 System、Common、Shared 加载(在这最后⼀步,遵从双亲委派机制)

Tomcat 对 Https 的⽀持及 Tomcat 性能优化策略

Tomcat 对 HTTPS 的⽀持

Https是⽤来加强数据传输安全的

HTTPS 简介

在这里插入图片描述
Http超⽂本传输协议,明⽂传输 ,传输不安全,https在传输数据的时候会对数据进⾏加密
ssl协议
TLS(transport layer security)协议

HTTPS和HTTP的主要区别

  • HTTPS协议使⽤时需要到电⼦商务认证授权机构(CA)申请SSL证书
  • HTTP默认使⽤8080端⼝,HTTPS默认使⽤8443端⼝
  • HTTPS则是具有SSL加密的安全性传输协议,对数据的传输进⾏加密,效果上相当于HTTP的升级版
  • HTTP的连接是⽆状态的,不安全的;HTTPS协议是由SSL+HTTP协议构建的可进⾏加密传输、身份认证的⽹络协议,⽐HTTP协议安全

HTTPS⼯作原理
在这里插入图片描述

Tomcat 对 HTTPS 的⽀持

  1. 使⽤ JDK 中的 keytool ⼯具⽣成免费的秘钥库⽂件(证书)。

    keytool -genkey -alias learn -keyalg RSA -keystore learn.keystore

    在这里插入图片描述

  2. 配置conf/server.xml

    <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"maxThreads="150" schema="https" secure="true" SSLEnabled="true"> <SSLHostConfig> <CertificatecertificateKeystoreFile="/Users/leo/workspace/servers/apache-tomcat-8.5.50/conf/lagou.keystore" certificateKeystorePassword="learn123" type="RSA" /></SSLHostConfig></Connector>
  3. 使⽤https协议访问8443端⼝(https://localhost:8443)

Tomcat 性能优化策略

系统性能的衡量指标,主要是响应时间和吞吐量

  • 响应时间:执⾏某个操作的耗时;
  • 吞吐量:系统在给定时间内能够⽀持的事务数量,单位为TPS(Transactions PerSecond的缩写,也就是事务数/秒,⼀个事务是指⼀个客户机向服务器发送请求然后服务器做出反应的过程。

Tomcat优化从两个⽅⾯进⾏

  • JVM虚拟机优化(优化内存模型)
  • Tomcat⾃身配置的优化(⽐如是否使⽤了共享线程池?IO模型?)

优化的原则
提供给⼤家优化思路,没有说有明确的参数值⼤家直接去使⽤,必须根据⾃⼰的真实⽣产环境来进⾏调整,调优是⼀个过程

虚拟机运⾏优化(参数调整)

Java 虚拟机的运⾏优化主要是内存分配和垃圾回收策略的优化:

  • 内存直接影响服务的运⾏效率和吞吐量

  • 垃圾回收机制会不同程度地导致程序运⾏中断(垃圾回收策略不同,垃圾回收次数和回收效率都是不同的)

  • Java 虚拟机内存相关参数

    参数 参数作⽤ 优化建议
    -server 启动Server,以服务端模式运⾏ 服务端模式建议开启
    -Xms 最⼩堆内存 建议与-Xmx设置相同
    -Xmx 最⼤堆内存 建议设置为可⽤内存的80%
    -XX:MetaspaceSize 元空间初始值
    -XX:MaxMetaspaceSize 元空间最⼤内存 默认⽆限
    -XX:NewRatio 年轻代和⽼年代⼤⼩⽐值,取值为整数,默认为2 不需要修改
    -XX:SurvivorRatio Eden区与Survivor区⼤⼩的⽐值,取值为整数,默认为8 不需要修改
  • JVM内存模型
    在这里插入图片描述

  • 参数调整示例

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

    调整后查看可使⽤JDK提供的内存映射⼯具
    在这里插入图片描述

垃圾回收(GC)策略

垃圾回收性能指标

  • 吞吐量:⼯作时间(排除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"
Tomcat 配置调优

Tomcat⾃身相关的调优

  • 调整tomcat线程池
    在这里插入图片描述

  • 调整tomcat的连接器
    调整tomcat/conf/server.xml 中关于链接器的配置可以提升应⽤服务器的性能。

    参数 说明
    maxConnections 最⼤连接数,当到达该值后,服务器接收但不会处理更多的请求, 额外的请求将会阻塞直到连接数低于maxConnections 。可通过ulimit -a 查看服务器限制。对于CPU要求更⾼(计算密集型)时,建议不要配置过⼤ ; 对于CPU要求不是特别⾼时,建议配置在2000左右(受服务器性能影响)。 当然这个需要服务器硬件的⽀持
    maxThreads 最⼤线程数,需要根据服务器的硬件情况,进⾏⼀个合理的设置
    acceptCount 最⼤排队等待数,当服务器接收的请求数量到达maxConnections ,此时Tomcat会将后⾯的请求,存放在任务队列中进⾏排序, acceptCount指的就是任务队列中排队等待的请求数 。 ⼀台Tomcat的最⼤的请求处理数量,是maxConnections+acceptCount
  • 禁⽤ A JP 连接器
    在这里插入图片描述

  • 调整 IO 模式
    Tomcat8之前的版本默认使⽤BIO(阻塞式IO),对于每⼀个请求都要创建⼀个线程来处理,不适合⾼并发;Tomcat8以后的版本默认使⽤NIO模式(⾮阻塞式IO)
    在这里插入图片描述
    当Tomcat并发性能有较⾼要求或者出现瓶颈时,我们可以尝试使⽤APR模式,APR(Apache PortableRuntime)是从操作系统级别解决异步IO问题,使⽤时需要在操作系统上安装APR和Native(因为APR原理是使⽤使⽤JNI技术调⽤操作系统底层的IO接⼝)

  • 动静分离
    可以使⽤Nginx+Tomcat相结合的部署⽅案,Nginx负责静态资源访问,Tomcat负责Jsp等动态资源访问处理(因为Tomcat不擅⻓处理静态资源)。