文章 78
评论 0
浏览 8357
6-Tomcat 性能优化

6-Tomcat 性能优化

6 Tomcat 性能优化

在目前流行的互联网架构中,Tomcat在目前的网络编程中是举足轻重的,由于Tomcat的运行依赖于JVM,从虚拟机的角度把Tomcat的调整分为外部环境调优 JVM 和 Tomcat 自身调优两部分

6.1 JVM组成

[15:53:34 root@tomcat1 tomcat]#java -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)

6.1.1 JVM组成

clipboard.png

JVM 组成部分

  • 类加载子系统: 使用Java语言编写.java Source Code文件,通过javac编译成.class Byte Code文件。class loader类加载器将所需所有类加载到内存,必要时将类实例化成实例
  • 运行时数据区: 最消耗内存的空间,需要优化
  • 执行引擎: 包括JIT (JustInTimeCompiler)即时编译器, GC垃圾回收器
  • 本地方法接口: 将本地方法栈通过JNI(Java Native Interface)调用Native Method Libraries, 比如:C,C++库等,扩展Java功能,融合不同的编程语言为Java所用

JVM运行时数据区域由下面部分构成:

  • Method Area 方法区(线程共享): 所有线程共享的内存空间,存放已加载的类信息(构造方法,接口定义),常量(final),静态变量(static), 运行时常量池等。但实例变量存放在堆内存中. 从JDK8开始此空间由永久代改名为元空间
  • heap 堆(线程共享): 虚拟机启动时创建,存放创建的所有对象信息。如果对象无法申请到可用内存将抛出OOM异常.堆是靠GC垃圾回收器管理的,通过-Xmx -Xms 指定最大堆和最小堆空间大小
  • Java stack Java栈(线程私有): 每个线程会分配一个栈,存放java中8大基本数据类型,对象引用,实例的本地变量,方法参数和返回值等,基于FILO()(First In Last Out),每个方法为一个栈帧
  • Program Counter Register PC寄存器(线程私有): 就是一个指针,指向方法区中的方法字节码,每一个线程用于记录当前线程正在执行的字节码指令地址。由执行引擎读取下一条指令.因为线程需要切换,当一个线程被切换回来需要执行的时候,知道执行到哪里了
  • Native Method stack 本地方法栈(线程私有): 为本地方法执行构建的内存空间,存放本地方法执行时的局部变量、操作数等。所谓本地方法,使用native 关健字修饰的方法,比如:Thread.sleep方法. 简单的说是非Java实现的方法,例如操作系统的C编写的库提供的本地方法,Java调用这些本地方法接口执行。但是要注意,本地方法应该避免直接编程使用,因为Java可能跨平台使用,如果用了Windows API,换到了Linux平台部署就有了问题

6.1.2 虚拟机

目前Oracle官方使用的是HotSpot, 它最早由一家名为"Longview Technologies"公司设计,使用了很多优秀的设计理念和出色的性能,1997年该公司被SUN公司收购。后来随着JDK一起发布了HotSpotVM。目前HotSpot是最主要的VM。

安卓程序需要运行在JVM上,而安卓平台使用了Google自研的Java虚拟机——Dalvid,适合于内存、处理器能力有限系统。

6.2 GC (Garbage Collection) 垃圾收集器

在堆内存中如果创建的对象不再使用,仍占用着内存,此时即为垃圾.需要即使进行垃圾回收,从而释放内存空间给其它对象使用

其实不同的开发语言都有垃圾回收问题,C,C++需要程序员人为回收,造成开发难度大,容易出错等问题,但执行效率高,而JAVA和Python中不需要程序员进行人为的回收垃圾,而由JVM或相关程序自动回收垃圾,减轻程序员的开发难度,但可能会造成执行效率低下

堆内存里面经常创建、销毁对象,内存也是被使用、被释放。如果不妥善处理,一个使用频繁的进程,可能会出现虽然有足够的内存容量,但是无法分配出可用内存空间,因为没有连续成片的内存了,内存全是碎片化的空间。

所以需要有合适的垃圾回收机制,确保正常释放不再使用的内存空间,还需要保证内存空间尽可能的保持

一定的连续

对于垃圾回收,需要解决三个问题

  • 哪些是垃圾要回收
  • 怎么回收垃圾
  • 什么时候回收垃圾

6.2.1 Garbage 垃圾确定方法

  • 引用计数: 每一个堆内对象上都与一个私有引用计数器,记录着被引用的次数,引用计数清零,该对象所占用堆内存就可以被回收。循环引用的对象都无法将引用计数归零,就无法清除。Python中即使用此种方式
  • 根搜索(可达)算法 Root Searching

clipboard.png

6.2.2 垃圾回收基本算法

6.2.2.1 标记-清除 Mark-Sweep

分垃圾标记阶段和内存释放阶段。标记阶段,找到所有可访问对象打个标记。清理阶段,遍历整个堆,对未标记对象(即不再使用的对象)清理。

clipboard.png
clipboard.png

标记-清除最大的问题会造成内存碎片,但是效率很高,不浪费空间

6.2.2.2 标记-压缩 (压实)Mark-Compact

分垃圾标记阶段和内存整理阶段。标记阶段,找到所有可访问对象打个标记。内存清理阶段时,整理时将对象向内存一端移动,整理后存活对象连续的集中在内存一端

clipboard.png

标记-压缩算法好处是整理后内存空间连续分配,有大段的连续内存可分配,没有内存碎片。
缺点是内存整理过程有消耗,效率相对低下

6.2.2.3 复制 Copying

先将可用内存分为大小相同两块区域A和B,每次只用其中一块,比如A。当A用完后,则将A中存活的对象复制到B。复制到B的时候连续的使用内存,最后将A一次性清除干净。

缺点是比较浪费内存,只能使用原来一半内存,因为内存对半划分了,复制过程毕竟也是有代价。

好处是没有碎片,复制过程中保证对象使用连续空间

6.2.2.4 多种算法总结

没有最好的算法,在不同场景选择最合适的算法

  • 效率: 复制算法>标记清除算法> 标记压缩算法
  • 内存整齐度: 复制算法=标记压缩算法> 标记清除算法
  • 内存利用率: 标记压缩算法=标记清除算法>复制算法

STW

对于大多数垃圾回收算法而言,GC线程工作时,停止所有工作的线程,称为Stop The World。GC 完成时,恢复其他工作线程运行。这也是JVM运行中最头疼的问题。

6.2.3 分代堆内存GC策略

上述垃圾回收算法都有优缺点,能不能对不同数据进行区分管理,不同分区对数据实施不同回收策略,分而治之。

6.2.3.1 堆内存分代

将heap内存空间分为三个不同类别: 年轻代、老年代、持久代

clipboard.png
clipboard.png
clipboard.png

Heap堆内存分为

  • 年轻代Young:Young Generation
    • 伊甸园区eden: 只有一个,刚刚创建的对象
    • 幸存(存活)区Servivor Space:有2个幸存区,一个是from区,一个是to区。大小相等、地位相同、可互换。
      • from 指的是本次复制数据的源区
      • to 指的是本次复制数据的目标区
  • 老年代Tenured:Old Generation, 长时间存活的对象

默认空间大小比例:

clipboard.png

永久代: JDK1.7之前使用, 即Method Area方法区,保存JVM自身的类和方法,存储JAVA运行时的环境信息,JDK1.8后 改名为 MetaSpace,此空间不存在垃圾回收,关闭JVM会释放此区域内存,此空间物理上不属于heap内存,但逻辑上存在于heap内存

  • 永久代必须指定大小限制,字符串常量JDK1.7存放在永久代,1.8后存放在heap中
  • MetaSpace 可以设置,也可不设置,无上限

规律: 一般情况99%的对象都是临时对象

范例: 在tomcat 状态页可以看到以下的内存分代
clipboard.png

范例: 查看JVM内存分配情况

[19:46:16 root@tomcat1 tomcat]#cat Heap.java 
public class Heap {
    public static void main(String[] args){
        //返回虚拟机试图使用的最大内存,字节单位
        long max = Runtime.getRuntime().maxMemory();
        //返回JVM初始化总内存
        long total = Runtime.getRuntime().totalMemory();

        System.out.println("max="+max+"字节\t"+(max/(double)1024/1024)+"MB");
        System.out.println("total="+total+"字节\t"+(total/(double)1024/1024)+"MB");
    }
}
[19:46:49 root@tomcat1 tomcat]#javac Heap.java 

[19:47:02 root@tomcat1 tomcat]#java -classpath . Heap
max=243269632字节	232.0MB
total=16252928字节	15.5MB

[19:48:07 root@tomcat1 tomcat]#java -XX:+PrintGCDetails -classpath . Heap
max=243269632字节	232.0MB
total=16252928字节	15.5MB
Heap
 def new generation   total 4928K, used 530K [0x00000000f1000000, 0x00000000f1550000, 0x00000000f6000000)
  eden space 4416K,  12% used [0x00000000f1000000, 0x00000000f1084b00, 0x00000000f1450000)
  from space 512K,   0% used [0x00000000f1450000, 0x00000000f1450000, 0x00000000f14d0000)
  to   space 512K,   0% used [0x00000000f14d0000, 0x00000000f14d0000, 0x00000000f1550000)
 tenured generation   total 10944K, used 0K [0x00000000f6000000, 0x00000000f6ab0000, 0x0000000100000000)
   the space 10944K,   0% used [0x00000000f6000000, 0x00000000f6000000, 0x00000000f6000200, 0x00000000f6ab0000)
 Metaspace       used 2525K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 269K, capacity 386K, committed 512K, reserved 1048576K
[19:48:15 root@tomcat1 tomcat]#echo "scale=2;(4928+10944)/1024" |bc
15.50
#说明年轻代+老年代占用了所有heap空间, Metaspace实际不占heap空间,逻辑上存在于Heap
#默认JVM试图分配最大内存的总内存的1/4,初始化默认总内存为总内存的1/64

6.2.3.2 年轻代回收 Minor GC

  1. 起始时,所有新建对象(特大对象直接进入老年代)都出生在eden,当eden满了,启动GC。这个称为Young GC 或者 Minor GC。
  2. 先标记eden存活对象,然后将存活对象复制到s0(假设本次是s0,也可以是s1,它们可以调换),eden剩余所有空间都清空。GC完成。
  3. 继续新建对象,当eden满了,启动GC。
  4. 先标记eden和s0中存活对象,然后将存活对象复制到s1。将eden和s0清空,此次GC完成
  5. 继续新建对象,当eden满了,启动GC。
  6. 先标记eden和s1中存活对象,然后将存活对象复制到s0。将eden和s1清空,此次GC完成

以后就重复上面的步骤。

通常场景下,大多数对象都不会存活很久,而且创建活动非常多,新生代就需要频繁垃圾回收。

但是,如果一个对象一直存活,它最后就在from、to来回复制,如果from区中对象复制次数达到阈值(默认15次,CMS为6次,可通过java的选项 -XX:MaxTenuringThreshold=N 指定),就直接复制到老年代。

6.2.3.3 老年代回收 Major GC

进入老年代的数据较少,所以老年代区被占满的速度较慢,所以垃圾回收也不频繁。

如果老年代也满了,会触发老年代GC,称为Old GC或者 Major GC。

由于老年代对象一般来说存活次数较长,所以较常采用标记-压缩算法。

当老年代满时,会触发 Full GC,即对所有"代"的内存进行垃圾回收

Minor GC比较频繁,Major GC较少。但一般Major GC时,由于老年代对象也可以引用新生代对象,所以先进行一次Minor GC,然后在Major GC会提高效率。可以认为回收老年代的时候完成了一次FullGC。

所以可以认为 MajorGC = FullGC

6.2.3.4 GC 触发条件

clipboard.png

Minor GC 触发条件:当eden区满了触发

Full GC 触发条件:

  • 老年代满了
  • System.gc()手动调用。不推荐

年轻代:

  • 存活时长低
  • 适合复制算法

老年代:

  • 区域大,存活时长高
  • 适合标记清除和标记压缩算法

6.2.4 java 内存调整相关参数

6.2.4.1 JVM 内存常用相关参数

Java 命令行参考文档: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

clipboard.png

帮助:man java

选项分类

  • -选项名称 此为标准选项,所有HotSpot都支持
  • -X选项名称 此为稳定的非标准选项
  • -XX:选项名称 非标准的不稳定选项,下一个版本可能会取消

clipboard.png

范例: 查看java的选项帮助

#查看java命令标准选项
[19:54:24 root@tomcat1 ~]#java
#查看java的非标准选项
[19:54:24 root@tomcat1 ~]#java -X
#查看所有不稳定选项的当前生效值
[19:55:31 root@tomcat1 ~]#java -XX:+PrintFlagsFinal
#查看所有不稳定选项的默认值
[19:56:02 root@tomcat1 ~]#java -XX:+PrintFlagsInitial
#查看当前命令行的使用的选项设置
[19:56:40 root@tomcat1 ~]#java -XX:+PrintCommandLineFlags
-XX:InitialHeapSize=15598016 -XX:MaxHeapSize=249568256 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops 
#上面的-XX:+UseParallelGC 说明当前使用Parallel Scavenge + Parallel Old

范例: 查看OOM

[19:58:38 root@tomcat1 ~]#cat HeapOom2.java 
import java. util. Random;
public class HeapOom2 {
	public static void main(String[] args) {
		String str = "I am lao wang";
		while (true){
			str += str + new Random().nextInt(88888888);
		}
	}
}

[19:58:47 root@tomcat1 ~]#javac HeapOom2.java 
[20:03:02 root@tomcat1 ~]#java  -Xms100m -Xmx100m -XX:+PrintGCDetails -classpath . HeapOom2 
[GC (Allocation Failure) [DefNew: 27099K->2929K(30720K), 0.0128489 secs] 27099K->5601K(99008K), 0.0128768 secs] [Times: user=0.00 sys=0.02, real=0.01 secs] 
[GC (Allocation Failure) [DefNew: 30190K->0K(30720K), 0.0503294 secs] 32862K->13617K(99008K), 0.0503605 secs] [Times: user=0.00 sys=0.02, real=0.05 secs] 
[GC (Allocation Failure) [DefNew: 10688K->0K(30720K), 0.0436912 secs] 24305K->24305K(99008K), 0.0437188 secs] [Times: user=0.00 sys=0.03, real=0.05 secs] 
[GC (Allocation Failure) [DefNew: 21376K->0K(30720K), 0.0688476 secs] 45681K->45681K(99008K), 0.0688720 secs] [Times: user=0.00 sys=0.06, real=0.07 secs] 
[GC (Allocation Failure) [DefNew: 21844K->0K(30720K), 0.0844690 secs] 67525K->67057K(99008K), 0.0844960 secs] [Times: user=0.00 sys=0.05, real=0.08 secs] 
[GC (Allocation Failure) [DefNew: 21376K->21376K(30720K), 0.0000175 secs][Tenured: 67057K->34992K(68288K), 0.0102542 secs] 88433K->34992K(99008K), [Metaspace: 2479K->2479K(1056768K)], 0.0104149 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
[Full GC (Allocation Failure) [Tenured: 34992K->32307K(68288K), 0.0067376 secs] 34992K->32307K(99008K), [Metaspace: 2479K->2479K(1056768K)], 0.0067600 secs] [Times: user=0.00 sys=0.01, real=0.00 secs] 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
	at java.lang.StringBuilder.append(StringBuilder.java:208)
	at HeapOom2.main(HeapOom2.java:6)
Heap
 def new generation   total 30720K, used 1038K [0x00000000f9c00000, 0x00000000fbd50000, 0x00000000fbd50000)
  eden space 27328K,   3% used [0x00000000f9c00000, 0x00000000f9d03928, 0x00000000fb6b0000)
  from space 3392K,   0% used [0x00000000fba00000, 0x00000000fba00000, 0x00000000fbd50000)
  to   space 3392K,   0% used [0x00000000fb6b0000, 0x00000000fb6b0000, 0x00000000fba00000)
 tenured generation   total 68288K, used 32307K [0x00000000fbd50000, 0x0000000100000000, 0x0000000100000000)
   the space 68288K,  47% used [0x00000000fbd50000, 0x00000000fdcdcc80, 0x00000000fdcdce00, 0x0000000100000000)
 Metaspace       used 2513K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 268K, capacity 386K, committed 512K, reserved 1048576K

6.2.4.2 JDK 工具监控使用情况

Jprofiler定位OOM的问题原因

JProfiler官网:http://www.ej-technologies.com/products/jprofiler/overview.html

JProfiler是一款功能强大的Java开发分析工具,它可以快速的帮助用户分析出存在的错误,软件还可对需要的显示类进行标记,包括了内存的分配情况和信息的视图等

范例: 安装jprofiler工具定位OOM原因和源码问题的位置

#安装OpenJDK
[root@centos8 ~]#dnf -y install java-1.8.0-openjdk-devel

[20:10:38 root@tomcat1 ~]#java  -Xms100m -Xmx100m -XX:+HeapDumpOnOutOfMemoryError -classpath . HeapOom2 
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid7118.hprof ...
Heap dump file created [33830224 bytes in 0.135 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
	at java.lang.StringBuilder.append(StringBuilder.java:208)
	at HeapOom2.main(HeapOom2.java:6)
[20:10:41 root@tomcat1 ~]#ls
HeapOom2.class  HeapOom2.java  java_pid7118.hprof

下载并安装Jprofiler
clipboard.png
clipboard.png

6.2.4.3 Tomcat的JVM参数设置

默认不指定,-Xmx大约使用了1/4的内存,当前本机内存指定约为1G。

在bin/catalina.sh中增加一行

......
# OS specific support. $var _must_ be set to either true or false.
#添加下面一行
JAVA_OPTS="-server -Xms128m -Xmx512m -XX:NewSize=48m -XX:MaxNewSize=200m"
                                                           
cygwin=false
darwin=false
........

-server:VM运行在server模式,为在服务器端最大化程序运行速度而优化
-client:VM运行在Client模式,为客户端环境减少启动时间而优化

重启 Tomcat 观察

[14:27:11 root@tomcat1 tomcat]#ps aux | grep tomcat
tomcat      1636 23.8 22.7 2520556 221596 ?      Sl   14:25   0:19 /usr/local/jdk/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -Xms128m -Xmx512m -XX:NewSize=48m -XX:MaxNewSize=200m -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat -Dcatalina.home=/usr/local/tomcat -Djava.io.tmpdir=/usr/local/tomcat/temp org.apache.catalina.startup.Bootstrap start
root        1686  0.0  0.1  12112  1080 pts/0    R+   14:27   0:00 grep --color=auto tomcat

浏览器访问server status页面,可以看到以下页面
clipboard.png

6.2.5 垃圾收集方式

按工作模式不同:指的是GC线程和工作线程是否一起运行

  • 独占垃圾回收器:只有GC在工作,STW 一直进行到回收完毕,工作线程才能继续执行
  • 并发垃圾回收器:让GC线程垃圾回收某些阶段可以和工作线程一起进行,如:标记阶段并行,回收阶段仍然串行

按回收线程数:指的是GC线程是否串行或并行执行

  • 串行垃圾回收器:一个GC线程完成回收工作
  • 并行垃圾回收器:多个GC线程同时一起完成回收工作,充分利用CPU资源

clipboard.png

6.2.6 调整策略

对JVM调整策略应用极广

  • 在WEB领域中Tomcat等
  • 在大数据领域Hadoop生态各组件
  • 在消息中间件领域的Kafka等
  • 在搜索引擎领域的ElasticSearch、Solr等

注意: 在不同领域和场景对JVM需要不同的调整策略

  • 减少 STW 时长,串行变并行
  • 减少 GC 次数,要分配合适的内存大小

一般情况下,我们大概可以使用以下原则:

  • 客户端或较小程序,内存使用量不大,可以使用串行回收
  • 对于服务端大型计算,可以使用并行回收
  • 大型WEB应用,用户端不愿意等待,尽量少的STW,可以使用并发回收

6.2.7 垃圾回收器

6.2.7.1 常用垃圾回收器

clipboard.png

按分代设置不同垃圾回收器

新生代

  • 新生代串行收集器Serial:单线程、独占式串行,采用复制算法,简单高效但会造成STW
    clipboard.png

  • 新生代并行回收收集器PS(Parallel Scavenge):多线程并行、独占式,会产生STW, 使用复制算法

    • 关注调整吞吐量,此收集器关注点是达到一个可控制的吞吐量
    • 吞吐量 = 运行用户代码时间/(运行用户代码时间+垃圾收集时间),比如虚拟机总共运行100分钟,其中垃圾回收花掉1分钟,那吞吐量就是99%。
    • 高吞吐量可以高效率利用CPU时间,尽快完成运算任务,主要适合在后台运算而不需要太多交互的任务。
    • 除此之外,Parallel Scavenge 收集器具有自适应调节策略,它可以将内存管理的调优任务交给虚拟机去完成。自适应调节策略也是Parallel Scavenge与 ParNew 收集器的一个重要区别。
    • 和ParNew不同,PS不可以和老年代的CMS组合
  • 新生代并行收集器ParNew:就是Serial 收集器的多线程版,将单线程的串行收集器变成了多线程并行、独占式,使用复制算法,相当于PS的改进版

    • 经常和CMS配合使用,关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,适合需要与用户交互的程序,良好的响应速度能提升用户体验
      clipboard.png
      老年代:
  • 老年代串行收集器Serial Old:Serial Old是Serial收集器的老年代版本,单线程、独占式串行,回收算法使用标记压缩

  • 老年代并行回收收集器Parallel Old:多线程、独占式并行,回收算法使用标记压缩,关注调整吞吐量

    • Parallel Old收集器是Parallel Scavenge 收集器的老年代版本,这个收集器是JDK1.6之后才开始提供,从HotSpot虚拟机的垃圾收集器的图中也可以看出,Parallel Scavenge 收集器无法与CMS收集器配合工作,因为一个是为了吞吐量,一个是为了客户体验(也就是暂停时间的缩短)
  • CMS (Concurrent Mark Sweep并发标记清除算法) 收集器

    • 在某些阶段尽量使用和工作线程一起运行,减少STW时长(200ms以内), 提升响应速度,是互联网服务端BS系统上较佳的回收算法
    • 分为4个阶段:初始标记、并发标记、重新标记、并发清除,在初始标记、重新标记时需要STW。
      clipboard.png
  1. 初始标记:此过程需要STW(Stop The Word),只标记一下GC Roots能直接关联到的对象,速度很快。
  2. 并发标记:就是GC Roots进行扫描可达链的过程,为了找出哪些对象需要收集。这个过程远远慢于初始标记,但它是和用户线程一起运行的,不会出现STW,所有用户并不会感受到。
  3. 重新标记:为了修正在并发标记期间,用户线程产生的垃圾,这个过程会比初始标记时间稍微长一点,但是也很快,和初始标记一样会产生STW。
  4. 并发清理:在重新标记之后,对现有的垃圾进行清理,和并发标记一样也是和用户线程一起运行的,耗时较长(和初始标记比的话),不会出现STW。
  5. 由于整个过程中,耗时最长的并发标记和并发清理都是与用户线程一起执行的,所以总体上来说,CMS收集器的内存回收过程是与用户线程一起并发执行的。

以下收集器不再按明确的分代单独设置

  • G1(Garbage First)收集器
    • 是最新垃圾回收器,从JDK1.6实验性提供,JDK1.7发布,其设计目标是在多处理器、大内存服务器端提供优于CMS收集器的吞吐量和停顿控制的回收器。JDK9将G1设为默认的收集器,建议 JDK9版本以后使用。
    • 基于标记压缩算法,不会产生大量的空间碎片,有利于程序的长期执行。
    • 分为4个阶段:初始标记、并发标记、最终标记、筛选回收。并发标记并发执行,其它阶段STW只有GC线程并行执行。
    • G1收集器是面向服务端的收集器,它的思想就是首先回收尽可能多的垃圾(这也是GarbageFirst名字的由来)
    • G1能充分的利用多CPU,多核环境下的硬件优势,使用多个CPU来缩短STW停顿的时间(10ms以内)。
    • 可预测的停顿:这是G1相对于CMS的另一大优势,G1和CMS一样都是关注于降低停顿时间,但是G1能够让使用者明确的指定在一个M毫秒的时间片段内,消耗在垃圾收集的时间不得超过N毫秒。
    • 通过此选项指定: +UseG1GC
  • ZGC收集器: 减少SWT时长(1ms以内), 可以PK C++的效率,目前实验阶段
  • Shenandoah收集器: 和ZGC竞争关系,目前实验阶段
  • Epsilon收集器: 调试 JDK 使用,内部使用,不用于生产环境

JVM 1.8 默认的垃圾回收器:PS + ParallelOld,所以大多数都是针对此进行调优

6.2.7.2 垃圾收集器设置

优化调整Java 相关参数的目标: 尽量减少FullGC和STW

通过以下选项可以单独指定新生代、老年代的垃圾收集器

  • -server 指定为Server模式,也是默认值,一般使用此工作模式
  • -XX:+UseSerialGC
    • 运行在Client模式下,新生代是Serial, 老年代使用SerialOld
  • -XX:+UseParNewGC
    • 新生代使用ParNew,老年代使用SerialOld
  • -XX:+UseParallelGC
    • 运行于server模式下,新生代使用Serial Scavenge, 老年代使用SerialOld
  • -XX:+UseParallelOldGC
    • 新生代使用Paralell Scavenge, 老年代使用Paralell Old
    • -XX:ParallelGCThreads=N,在关注吞吐量的场景使用此选项增加并行线程数
  • -XX:+UseConcMarkSweepGC
    • 新生代使用ParNew, 老年代优先使用CMS,备选方式为Serial Old
    • 响应时间要短,停顿短使用这个垃圾收集器
    • -XX:CMSInitiatingOccupancyFraction=N,N为0-100整数表示达到老年代的大小的百分比多少触发回收
      • 默认68
    • -XX:+UseCMSCompactAtFullCollection 开启此值,在CMS收集后,进行内存碎片整理
    • -XX:CMSFullGCsBeforeCompaction=N 设定多少次CMS后,进行一次内存碎片整理
    • -XX:+CMSParallelRemarkEnabled 降低标记停顿

范例:

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 -
XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5

范例: 查看默认模式

[14:27:13 root@tomcat1 tomcat]#java |& grep '-server'
-server	  to select the "server" VM
The default VM is server.
[14:47:13 root@tomcat1 tomcat]#tail -n 2 /usr/local/jdk/jre/lib/amd64/jvm.cfg
-server KNOWN
-client IGNORE

范例: 指定垃圾回收设置

#将参数加入到bin/catalina.sh中,重启观察Tomcat status。老年代已经使用CMS
[14:54:17 root@tomcat1 tomcat]#vim bin/catalina.sh
JAVA_OPTS="-server -Xms128m -Xmx512m -XX:NewSize=48m -XX:MaxNewSize=200m -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5"
[14:54:33 root@tomcat1 tomcat]#systemctl restart tomcat.service
[14:54:53 root@tomcat1 tomcat]#ps aux | grep tomcat
tomcat      1839 97.6 19.4 2551188 189360 ?      Sl   14:54   0:07 /usr/local/jdk/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -Xms128m -Xmx512m -XX:NewSize=48m -XX:MaxNewSize=200m -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5 -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat -Dcatalina.home=/usr/local/tomcat -Djava.io.tmpdir=/usr/local/tomcat/temp org.apache.catalina.startup.Bootstrap start

clipboard.png

开启垃圾回收输出统计信息,适用于调试环境的相关选项

  • -XX:+PrintGC 输出GC信息
  • -XX:+PrintGCDetails 输出GC详细信息
  • -XX:+PrintGCTimeStamps 与前两个组合使用,在信息上加上一个时间戳
  • -XX:+PrintHeapAtGC 生成GC前后椎栈的详细信息,日志会更大

注意: 以上适用调试环境,生产环境请移除这些参数,否则有非常多的日志输出

6.3 JVM相关工具

6.3.1 JVM 工具概述

$JAVA_HOME/bin下

clipboard.png

6.3.2 jps

JVM 进程状态工具

格式

jps:Java virutal machine Process Status tool,
jps [-q] [-mlvV] [< hostid>]
-q:静默模式;
-v:显示传递给jvm的命令行参数;
-m:输出传入main方法的参数;
-l:输出main类或jar完全限定名称;
-v:显示通过flag文件传递给jvm的参数;
[< hostid>]:主机id,默认为localhost;

6.3.3 jinfo

输出给定的java进程的所有配置信息

格式:

jinfo [option] < pid>
-flags:打印 VM flags
-sysprops:to print Java system properties
-flag < name>:to print the value of the named VM flag

6.3.4 jstat

输出指定的java进程的统计信息

格式:

jstat -help|-options
jstat -< option> [-t] [-h< lines>] < vmid> [< interval> [< count>]]
[< interval> [< count>]]
interval:时间间隔,单位是毫秒;
count:显示的次数;
#返回可用统计项列表
#jstat -options
-class:class loader
-compiler:JIT
-gc:gc
-gccapacity:统计堆中各代的容量
-gccause:
-gcmetacapacity
-gcnew:新生代
-gcnewcapacity
-gcold:老年代

范例:

[15:19:58 root@tomcat1 ~]#jps
2708 Jps
2606 HelloWorld
[15:20:04 root@tomcat1 ~]#jstat -gc 2606
S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
512.0  512.0   0.0    0.0    4416.0   442.4    10944.0      0.0     4480.0 875.3  384.0   76.6       0    0.000   0      0.000    0.000
S0C:S0区容量
YGC:新生代的垃圾回收次数
YGCT:新生代垃圾回收消耗的时长;
FGC:Full GC的次数
FGCT:Full GC消耗的时长
GCT:GC消耗的总时长
#3次,一秒一次
[15:21:21 root@tomcat1 ~]#jstat -gcnew 2606 1000 3

6.3.5 jstack

程序员常用堆栈情况查看工具

jstack:查看指定的java进程的线程栈的相关信息

格式:

jstack [-l] < pid>
jstack -F [-m] [-l] < pid>
-l:long listings,会显示额外的锁信息,因此,发生死锁时常用此选项
-m:混合模式,既输出java堆栈信息,也输出C/C++堆栈信息
-F:当使用"jstack -l PID"无响应,可以使用-F强制输出信息

6.3.6 jmap

Memory Map, 用于查看堆内存的使用状态

#查看进程堆内存情况
[root@tomcat ~]#jmap -heap 21407

6.3.7 jhat

Java Heap Analysis Tool 堆分析工具

格式

jmap [option]
#查看堆空间的详细信息:
jmap -heap

6.4 Tomcat 性能优化常用配置

6.4.1 内存空间优化

JAVA_OPTS="-server -Xms4g -Xmx4g -XX:NewSize= -XX:MaxNewSize= "
-server:服务器模式
-Xms:堆内存初始化大小
-Xmx:堆内存空间上限
-XX:NewSize=:新生代空间初始化大小
-XX:MaxNewSize=:新生代空间最大值

生产案例:

[root@centos8 ~]#vim /usr/local/tomcat/bin/catalina.sh
JAVA_OPTS="-server -Xms4g -Xmx4g -Xss512k -Xmn1g -
XX:CMSInitiatingOccupancyFraction=65 -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC
-XX:MaxTenuringThreshold=10 -XX:NewRatio=2
-XX:PermSize=128m -XX:MaxPermSize=512m -XX:CMSFullGCsBeforeCompaction=5
-XX:+ExplicitGCInvokesConcurrent -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods"

#一台tomcat服务器并发连接数不高,生产建议分配物理内存通常4G到8G较多,如果需要更多连接,一般会利用
虚拟化技术实现多台tomcat

6.4.2 线程池调整

[root@centos8 ~]#vim /usr/local/tomcat/conf/server.xml
< Connector port="8080" protocol="HTTP/1.1"  connectionTimeout="20000"
redirectPort="8443" />

常用属性:

  • connectionTimeout :连接超时时长,单位ms
  • maxThreads:最大线程数,默认200
  • minSpareThreads:最小空闲线程数
  • maxSpareThreads:最大空闲线程数
  • acceptCount:当启动线程满了之后,等待队列的最大长度,默认100
  • URIEncoding:URI 地址编码格式,建议使用 UTF-8
  • enableLookups:是否启用客户端主机名的DNS反向解析,缺省禁用,建议禁用,就使用客户端IP就行
  • compression:是否启用传输压缩机制,建议 "on",CPU和流量的平衡
    • compressionMinSize:启用压缩传输的数据流最小值,单位是字节
    • compressableMimeType:定义启用压缩功能的MIME类型text/html, text/xml, text/css,text/javascript

6.4.3 Java压力测试工具

PerfMa 致力于打造一站式IT系统稳定性保障解决方案,专注于性能评测与调优、故障根因定位与解决,为企业提供一系列技术产品与专家服务,提升系统研发与运行质量。

#社区产品
https://opts.console.perfma.com/

标题:6-Tomcat 性能优化
作者:Carey
地址:HTTPS://zhangzhuo.ltd/articles/2021/03/21/1616307057456.html

生而为人

取消