8.1  Tomcat概述

8.1.1  Tomcat介绍

        自从 JSP 发布之后,推出了各式各样的 JSP 引擎。Apache Group 在完成 GNUJSP1.0的开发以后，开始考虑在 SUN 的 JSWDK 基础上开发一个可以直接提供 Web 服务的 JSP服务器，当然同时也支持 Servlet, 这样 Tomcat 就诞生了。
        Tomcat是 Apache 软件基金会(Apache Software Foundation)Jakarta 项目中的一个核心项目，由 Apache、Sun 和其他一些公司及个人共同开发而成。其被 JavaWorld 杂志的编辑选为 2001 年度最具创新的 Java 产品，同时它又是 Sun 公司官方推荐的 Servlet和 JSP 容器，因此 Tomcat越来越多的受到软件公司和开发人员的喜爱。由于有了 Sun 的参与和支持，最新的 Servet 和 JSP 规范总是能在 Tomcat 中得到体现，Tomcat5 支持最新的 Servlet 2.4 和 JSP 2.0 规范。因为 Tomcat 技术先进、性能稳定、免费,因而深受 Java爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web 应用服务器。
        Tomcat 服务器是一个免费的开放源代码的 Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试 JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应 HTML(标准通用标记语言下的一个应用)页面的访问请求。实际上，Tomcat是Apache 服务器的扩展，但运行时它是独立运行的，所以当运行 Tomcat 时，它实际上作为一个与 Apache 独立的进程单独运行的。

        当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行 JSP 页面和Servlet。Tomcat 和 IIS 等 Web 服务器一样，具有处理 HTML 页面的功能，另外它还是一个 Servlet 和 JSP 容器，独立的 Servlet 容器是 Tomcat 的默认模式。不过，Tomcat 处理静态 HTML 的能力不如 Apache 服务器。

8.1.2  Tomcat核心组件

        通常意义上的 Web 服务器接受请求后，只是单纯地响应静态资源(如 HTML 文件、图片文件等)，不能在后端进行一定的处理操作。 Tomcat是 Apache 下的一个子项目，它具备 Web 服务器的所有功能，不仅可以监听接受请求并响应静态资源，而且可以在后端运行特定规范的 Java 代码 Servlet，同时将执行的结果以 HTML 代码的形式返回客户端。

• Web 容器:完成 Web 服务器的功能。
• Servlet 容器:名字为catalina，用于处理 Servlet 代码。
• JSP 容器:用于将 JSP 动态网页翻译成 Servlet 代码。

8.1.3Tomcat  请求处理

• 用户在浏览器中输入网址 localhost:8080/testindexjsp,请求被发送到本机端口 8080,被在那里监听的 Coyote HTTP/1.1 Connector 获得;
• Connector 把该请求交给它所在的 Service 的 Engine(Container)来处理，并等待Engine 的回应;
• Engine 获得请求 localhost/test/index.jsp，匹配所有的虚拟主机 Host;
• Engine 匹配到名为 localhost 的 Host(即使匹配不到也把请求交给该 Host 处理，因为该 Host 被定义为该 Engine 的默认主机)，名为 localhost 的 Host 获得请求/testindex.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;
• onnector把 HttpServletResponse 对象返回给客户 Browser。

8.2 Tomcat服务部署

8.2.1  下载并安装JDK

        

        在部署 Tomcat 之前必须安装好 JDK，因为 JDK是 Tomcat 运行的必要环境。JDK 的安装相对比较简单，版本有很多，本章选择基于linux64 位 RPM 版本。

rpm -ivh jdk-8u171-linux-x64.rpm

        上面显示安装完成，jdk安装目录在/usr/iava/idk1.8.0 171-amd64，编辑/etc/profile文件，设置idk 的环境变量。具体操作如下。

8.2.2 安装启动Tomcat

1. 安装Tomcat服务
   从Tomcat官网下载 apache-tomcat-9.0.8.tar.gz稳定版本,将安装包解压后移动 Tomcat目录到/usr/local 下面，然后执行/usr/local/tomcatlbin/startup.sh 命令启动 Tomcat 即可。具体操作如下。
   浏览器访问http://192.168.9.236:8080会出现Tomcat的欢迎页
2. 优化Tomcat服务启动时间
   查看日志会发现 Tomcat 第一次启动很慢，默认情况下都需要几十秒。修改 JDK 参数可以改善该状况，打开/usr/java/jdk1.8.0_171-amd64/jre/ib/security/java.security 文件，找修改如下内容:securerandom.source=file:/dev/random成到securerandom.source=file:/dev/urandom。然后重启 Tomcat 就会发现启动时间变短很多。
3. Tomcat目录结构
   执行 ll/usr/local/tomcat命令即可查看 Tomcat 安装后目录结构

    ll/usr/local/tomcat

    bin 目录:用于存放启动和关闭 Tomcat 的脚本文件，比较常用的是 catalina.sh、startup.sh、shutdown.sh三个文件。
   
   conf 目录:用于存放 Tomcat 服务器的各种配置文件，比较常用的是 server.xml、context.xml、tomcat-users.xml、web.xml 四个文件。
   
   lib 目录:用于存放 Tomcat 服务器的jar 包，一般不作任何改动，除非连接第三方服务,比如 redis，那就需要添加相对应的jar 包。
   
   logs 目录:用于存放 Tomcat 日志。
   
   temp 目录:用于存放 Tomcat 运行时产生的文件。
   
   webapps 日录:用于存放项目资源的目录。
   
   work 目录:是Tomcat 工作目录，一般清除 Tomcat 缓存的时候会使用到。

8.3Tomcat配置与优化

8.3.1虚拟主机配置

1. 创建 www 和 bbs 项目目录和文件
   执行下面的命令，可以创建 www 和 bbs 项目目录和文件,
2. 修改 Tomcat 主配置文件
   修改 Tomcat 主配置文件/usr/local/tomcat/conf/server.xml，在</Host>下面增加如下内容
3. 虚拟主机访问测试
   客户端绑定两个域名需要写入本机 hosts，Tomcat 默认端口是 8080。
   使用浏览器访问 http://www.test.com:8080
   使用浏览器访问 http://bbs.test.com:8080,
   

8.3.2  Tomcat优化

        Tomcat 默认安装下的缺省配置并不适合生产环境，它会频繁出现假死现象需要重启只有通过不断压测优化才能让它最高效率稳定的运行。优化主要包括三方面，分别为操作系统优化(内核参数优化)，Tomcat配置文件参数优化，Java虚拟机(JVM)调优。其中最难理解的就是 JM 调优。系统优化本章不介绍，本章将配合jmeter压测工具进行调优前和调优后的数据进行比较。

1、Tomcat配置文件参数优化

• maxThreads:Tomcat 使用线程来处理接收的每个请求，这个值表示 Tomcat 可创建的最大的线程数，默认值是 200。
• minSpareThreads:最小空闲线程数，Tomcat 启动时的初始化线程数，表示即使没有人使用也开这么多空线程等待，默认值是 10。
• maxSpareThreads:最大备用线程数，一旦创建的线程超过这个值，Tomcat 就会关闭不再需要的 socket 线程。默认值是-1(无限制)，一般不需要指定。
• URlEncoding:指定 Tomcat 容器的 URL 编码格式，Tomcat 语言编码格式这块不如其它 Web 服务器软件配置方便，需要分别指定。
• connnectionTimeout:网络连接超时，单位:毫秒，设置为0表示永不超时，这样设置有隐患的。通常默认 20000 毫秒就可以。
• enableLookups:是否反查域名，以返回远程主机的主机名，取值为:true 或 false如果设置为 false，则直接返回 IP 地址，为了提高处理能力，应设置为 false。
• disableUploadTimeout:上传时是否使用超时机制。应设置为 true.
• connectionUploadTimeout:上传超时时间，毕竟文件上传可能需要消耗更多的时间，该参数需要根据自己的业务需要自行调整,以使 Servlet有较长的时间来完成它的执行,需要与上一个参数一起配合使用才会生效。
• acceptCount:指定当所有可以使用的处理请求的线程都被使用时，可传入连接请求的最大队列长度，超过这个数的请求将不予处理，默认为100个。
• compression:是否对响应的数据进行 GZIP 压缩，off 表示禁止压缩、on 表示允许压缩(文本将被压缩)、force 表示所有情况下都进行压缩，默认值为 off。压缩数据后可以有效的减少页面的大小，一般可以减小 1/3 左右，因而节省带宽。
• compressionMinSize:表示压缩响应的最小值，只有当响应报文大小大于这个值的时候才会对报文进行压缩，如果开启了压缩功能，默认值就是 2048。
• compressableMimeType:压缩类型，指定对哪些类型的文件进行数据压缩
• noCompressionUserAgents="gozilla, traviata":对于以下的浏览器，不启用压缩。

        如果已经对代码进行了动静分离，静态页面和图片等数据就不需要Tomcat 处理了，那么也就不需要在 Tomcat 中配置压缩了。因为这里只有一台 Tomcat 服务器，而且压测的是Tomcat 首页，会有图片和静态资源文件，所以这里启用压缩。

        以上是一些常用的配置参数,还有好多其它的参数设置,还可以继续深入的优化,HTTFConnector 与 AJP Connector 的参数属性值，可以参考官方文档的详细说明进行学习。链接地址 htp://tomcat.apache.org/tomcat-9.0-doc/config/http.html，下面开始对 Tomcat 配置文件优化进行前后的对比。

2、jmeter 压测工具

（1）客户端下载JDK

        从 Oracle 官方下载 JDK 软件,JDK 安装过程直接下一步即可。因为本章中所使用的客户端是 Windows 10，所以 JDK 使用 jdk-8u102-windows-x64 版本。

（2）运行jmeter 软件

        本章中是使用的imeter软件版本为apache-jmeter-3.1,双击运行apache-jmeter-3.1.rar压缩包->bin 目录->ApacheJMeter.jar 文件即可打开 jmeter 软件

（3）打开压测脚本进行压测

        点击左上角文件->打开->选择压测脚本
        单击第一排绿色三角按钮(鼠标指上去后会显示启动)开始进行压测

        压测脚本里设置的是 20 秒启动 4000 个线程数，并发为 2000，超时时间是 50000 毫秒。也可以适当的根据自己的需求进行修改。为了不那么复杂，从压测结果看只关注聚合报告，聚合报告只关注 Average、90% Line、Error%这三列，因为压测 Tomcat 首页压力不会太大，所以 Error 都是为0属于正常。先看一组优化前(默认的配置)压测截图

（4）修改Tomcat

        打开 Tomcat 主配置文件 server.xml，找到如下默认配置

        将 Tomcat 原本的默认配置修改为如下所示。

（5）修改配置参数后压测

        重新启动 Tomcat 服务器,jmeter 还是继续保持同样的参数进行压测,优化后压测截图

3、Java 虚拟机(JVM)调优

• -server:一定要作为第一个参数，只要 Tomcat 是运行在生产环境中，这个参数必须给加上，不然后面的参数不会生效
• -Xms:表示 Java 初始化堆的大小，-Xms 与-Xmx 设成一样的值，避免 JVM 反复重新申请内存，导致性能大起大落，默认值为物理内存的1164，默认(MinHeapFreeRatio参数可以调整)空余堆内存小于 40%时，JVM 就会增大堆直到-Xmx 的最大限制。
• -Xmx:表示最大 Java 堆大小，当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃,因此一般建议堆的最大值设置为物理内存的最大值的 50%。
• -XX:NewSize:设置新生代内存大小。
• -XX:MaxNewSize:设置最大新生代内存大小，
• -XX:PermSize:设置持久代内存大小。
• -XX:MaxPermSize:设置最大值持久代内存大小，永久代不属于堆内存，堆内存只包含新生代和老年代。
• XX:+AggressiveOpts:作用如其名(aggressive)，若启用这个参数，则每当 JDK版本升级时，JVM 都会使用最新加入的优化技术(如果有的话)。
• -XX:+UseBiasedLocking:启用一个优化了的线程锁，要知道在 appserver，每个 http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，这个优化了的线程锁使得 appserver 内对线程处理自动进行最优调配。
• -XX:+DisableExplicitGC:在程序代码中不允许有显示的调用“System.gc()”。每次在操作结束时手动调用 System.gc()一下，付出的代价就是系统响应时间严重降低，就和关于 Xms，Xmx 里的原理一样，这样去调用 GC 会导致系统的 JVM 大起大落。
• -XX:+UseParNewGC:对新生代采用多线程并行回收，这样收得快。需要注意的是在最新 JVM 版本中,当使用 -XX:+UseConcMarkSweepGC 时,-XX:UseParNewGC 会自动开启。因此,如果年轻代的并行 GC 不想开启,可以通过设置 -XX:-UseParNewGC来关掉。
• -XX:MaxTenuringThreshold:设置垃圾最大年龄。如果设置为0的话，则新生代对象不经过 Survivor 区，直接进入老年代。对于老年代比较多的应用(需要大量常驻内存的应用),可以提高效率。如果将此值设置为一 个较大值,则新生代对象会在 Survivor区进行多次复制，这样可以增加对象在新生代的存活时间，增加在新生代即被回收的概率，减少 Fu GC 的频率，这样做可以在某种程度上提高服务稳定性。该参数只有在串行 GC 时才有效，这个值的设置是根据本地的 jprofiler 监控后得到的一个理想的值，不能一概而论原搬照抄。
• -XX:+CMSParallelRemarkEnabled:在使用 UseParNewGC 的情况下，尽量减少
  mark 的时间。
• -XX:+UseCMSCompactAtFullCollection:在使用 concurrent gc 的情况下，防止memoryfragmention，对 live object 进行整理，使 memory 碎片减少。
• -XX:LargePageSizelnBytes:指定 Java heap 的分页页面大小，内存页的大小不可设置过大， 会影响 Perm 的大小。
• -XX:+UseFastAccessorMethods:使用 get，set方法转成本地代码，原始类型的快速优化。
• -XX:+UseCMSInitiatingOccupancyOnly:只有在 oldgeneration 在使用了初始化的比例后 concurrent collector 启动收集。
• -Duser.timezone=Asia/Shanghai:设置用户所在时区
• -Diava.awt.headless=true:这个参数一般我们都是放在最后使用。有时我们会在我们的 J2EE 工程中使用一些图表工具，如:ifreechart，用于在 Web 网页输出 GIFIJPG等流，在 Windows 环境下，一般我们的 app server 在输出图形时不会碰到什么问题,但是在 Linux/Unix 环境下经常会碰到一个 exception 导致你在 Windows 开发环境下图片正常显示，可是在 Linuxnix 下却显示不出来，因此加上这个参数以免避这样的情况出现。
• -Xmn:新生代的内存空间大小,注意:此处的大小是(eden+2survivorspace)。与 jmap-heap 中显示的 New gen 是不同的。整个堆大小 = 新生代大小 + 老生代大小 + 永久代大小。在保证堆大小不变的情况下，增大新生代后，将会减小老生代大小。此值对系统性能影响较大，Sun 官方推荐配置为整个堆的 3/8。
• -XX:CMSInitiatingOccupancyFraction:当堆满之后,并行收集器便开始进行垃圾收集。例如，当没有足够的空间来容纳新分配或提升的对象。对于CMS收集器，长时间等待是不可取的，因为在并发垃圾收集期间应用持续在运行(并且分配对象)。因此，为了在应用程序使用完内存之前完成垃圾收集周期,CMS收集器要比并行收集器更先启动。因为不同的应用会有不同对象分配模式，JVM 会收集实际的对象分配(和释放)的运行时数据，并且分析这些数据，来决定什么时候启动一次CMS 垃圾收集周期。这个参数设置有很大技巧本上满足基(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotion failed.例如在应用中Xmx是6000,Xmn 是512,那么 Xmx-Xmn 是 5488M,也就是老年代有 5488M，CMSInitiatingOccupancyFraction=90 说明老年代到 90%满的时候开始执行对老年代的并发垃圾回收(CMS)，这时还剩10%的空间是5488*10%=548M，所以即使 Xmn(也就是新生代共 512M)里所有对象都搬到老年代里，548M 的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed，因此这个参数的设置必须与 Xmn 关联在一起。
• -XX:+CMSIncrementalMode:该标志将开启 CMS 收集器的增量模式。增量模式经常暂停CMS 过程，以便对应用程序线程作出完全的让步。因此，收集器将花更长的时间完成整个收集周期。因此，只有通过测试后发现正常CMS周期对应用程序线程干扰太大时，才应该使用增量模式。由于现代服务器有足够的处理器来适应并发的垃圾收集，所以这种情况发生得很少，用于但 CPU 情况。
• -XX:NewRatio:年轻代(包括 Eden 和两个 Survivor 区)与年老代的比值(除去持久代)，-XX:NewRatio=4 表示年轻代与年老代所占比值为 1:4，年轻代占整个堆栈的115，Xms=Xmx 并且设置了Xmn 的情况下，该参数不需要进行设置。
• -XX:SurvivorRatio:Eden 区与 Survivor 区的大小比值，设置为 8，表示 2个Survivor 区(JVM 堆内存年轻代中默认有 2个大小相等的 Survivor 区)与1个Eden 区的比值为 2:8，即 1个 Survivor 区占整个年轻代大小的 1/10。
• -XX:+UseSerialGC:设置串行收集器，
• -XX:+UseParallelGC:设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。
• -XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集，JDK6.0 开始支持对年老代并行收集。
• -XX:ConcGCThreads:早期 JVM 版本也叫-XX:ParalleICMSThreads,定义并发 CMS过程运行时的线程数。比如value=4意味着CMS周期的所有阶段都以 4个线程来执行。尽管更多的线程会加快并发 CMS 过程，但其也会带来额外的同步开销。因此，对于特定的应用程序，应该通过测试来判断增加CMS 线程数是否真的能够带来性能的提升。如果还标志未设置，JM 会根据并行收集器中的-XX:ParallelGCThreads 参数的值来计算出默认的并行 CMS 线程数。
• -XX:ParallelGCThreads:配置并行收集器的线程数，即:同时有多少个线程一起进行垃圾回收，此值建议配置与 CPU 数目相等。
• -XX:OldSize:设置 JVM 启动分配的老年代内存大小，类似于新生代内存的初始大小-XX:NewSize.

        以上就是一些常用的配置参数,但是有些参数是可以被替代的,配置思路需要考虑的是Java 提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾能够接受的速度和应用有关,应该通过分析实际的垃圾收集的时间和频率来调整。假如堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。假如您把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为确保最好的性能，要把堆的大小设大，确保垃圾收集不在整个基准测试的过程中出现。

        测试前,先还原 Tomcat 到默认的配置文件,重启后压测一组优化前压测截图

        上述关于 JVM 优化参数太多，很多参数需要对 GC 回收有很深刻的认识。如果优化的不合适，往往会起到事倍功半的效果。下面是常见的优化参数，修改/usr/local/tomcat/bin/catalina.sh，增加红色字体。

        重启 Tomcat 服务再次进行一轮压测

8.4  常见错误说明

1.java.lang.OutOfMemoryError: Java heap space--JvM Heap(堆)溢出

        JVM 在启动的时候会自动设置 J Heap 的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)不可超过物理内存。可以利用 JVM 提供的 -Xmn -Xms -Xmx 等选项来进行设置。Heap 的大小是 Young Generation 和 Tenured Generaion 之和。在 JVM中如果 98%的时间是用于 GC，且可用的 Heap size 不足 2%的时候将抛出此异常信息。

        解决方法:手动设置 JVM Heap(堆)的大小。

2.java.lang.OutOfMemoryError: PermGen space-PermGen space 滥出

        PermGen space 的全称是 Permanent Generation space，是指内存的永久保存区域。为什么会内存溢出，这是由于这块内存主要是被 JVM 存放 Class 和 Meta 信息的，Class在被 Load 的时候被放入 PermGen space 区域,它和存放 Instance 的 Heap 区域不同,sun的 GC 不会在主程序运行期对 PermGen space 进行清理。所以，如果你的 APP 会载入很多 CLASS 的话，就很可能出现 PermGen space 溢出。
        解决方法:手动设置 MaxPermSize 大小。

3.java.lang.StackOverflowError--栈溢出

        JVM 依然是采用栈式的虚拟机，这个和 C与 Pascal 都是一样的。函数的调用过程都体现在堆栈和退栈上了。调用构造函数的“层”太多了，以致于把栈区溢出了。通常来讲，一般栈区远远小于堆区的，因为函数调用过程往往不会多于上千层，而即便每个函数调用需要1K 的空间(这个大约相当于在一个℃函数内声明了 256 个int 类型的变量)，那么栈区也不过是需要 1MB 的空间。通常栈的大小是 1-2MB 的。通常递归也不要递归的层次过多，很容易溢出。
        解决方法:修改程序。